CROSS REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to U.S. Provisional Patent Application No. 63/229,283 filed on August 4, 2021 , the disclosure of which is hereby incorporated by reference in its entirety.

BACKGROUND

1. Field

[0002] This disclosed subject matter relates generally to methods, systems, and computer program products for monitoring acquirer risk and, in particular embodiments or aspects, to a method, system, and computer program product for a framework for monitoring acquirer credit settlement risk.

2. Technical Considerations

[0003] Financial service providers can help prevent revenue loss by evaluating risk associated with acquiring banks and adjusting business decisions accordingly. However, acquirer risk is difficult to monitor due to economic instability. Credit settlement risk monitoring is used to help businesses avoid financial loss. Different types of data are available at different times (e.g., annual reports, quarterly reports, third-party scores, acquirer changes, merchant activities, news feeds, transactions, and/or the like). Existing methods and systems do not effectively deal with the frequency at which data is available and typically use simple, single-mode modeling (e.g., based on either supervised or unsupervised learning) of large data sets, which lacks flexibility. Further, existing methods and systems produce results which are not easily interpretable (e.g., it is hard to understand the reasons why the risk exists).

[0004] There is a need in the art for a technically improved method and system for monitoring and detecting acquirer risk to minimize losses that is comprehensive (e.g., can use multiple data sources), accurate (e.g., can choose the best model(s) to use for each type of data), flexible (e.g., easy to add and/or remove models), generic (e.g., using agnostic labels), and interpretable (e.g., the results can explain the reasons for risk). Further, there is a need for a modularized method and system that can dynamically and seamlessly link data as soon as it is available. SUMMARY

[0005] According to non-limiting embodiments or aspects, provided is a system comprising: a transaction database comprising a plurality of transaction records, each transaction record associated with an acquirer system and at least one merchant corresponding to the acquirer system; at least one processor in communication with the transaction database, the at least one processor programmed or configured to: generate a first acquirer risk score based on the plurality of transaction records and a first risk algorithm; generate a first merchant risk score based on the plurality of transaction records and the first risk algorithm; generate a second acquirer risk score based on the plurality of transaction records and a second risk algorithm; generate a second merchant risk score based on the plurality of transaction records and the second risk algorithm; and generate a final acquirer risk score based on the first acquirer risk score, the second acquirer risk score, the first merchant risk score, and the second merchant risk score.

[0006] In non-limiting embodiments or aspects, the at least one processor is further programmed or configured to: generate a third acquirer risk score based on the plurality of transaction records and a third risk algorithm; and generate a third merchant risk score based on the plurality of transaction records and the third risk algorithm, the final acquirer risk score is generated based on the first acquirer risk score, the second acquirer risk score, the third acquirer risk score, the first merchant risk score, the second merchant risk score, and the third merchant risk score. In non-limiting embodiments or aspects, generating the first acquirer risk score based on the plurality of transaction records and the first risk algorithm comprises: analyzing the plurality of transaction records based on a name entity recognition algorithm configured to recognize the acquirer system associated with each of the plurality of transaction records, the plurality of transaction records comprises a plurality of documents; and analyzing a concentration of the plurality of transaction records based on transaction payments for future services to determine a risk associated with future chargeback requests.

[0007] In non-limiting embodiments or aspects, generating the second acquirer risk score based on the plurality of transaction records and the second risk algorithm comprises: determining a time period associated with each of the plurality of transaction records; performing a time-series analysis of the plurality of transaction records based on the time period to detect a risk associated with abnormal transactions; generating a graph of the plurality of transaction records over a predetermined period of time; determining whether the graph indicates an abnormality by analyzing a pattern of the plurality of transaction records over the predetermined period of time; and generating the second acquirer risk score. In non-limiting embodiments or aspects, generating the third acquirer risk score based on the plurality of transaction records and the third risk algorithm comprises: generating at least one relational graph based on the plurality of transaction records, the at least one relational graph comprising a plurality of nodes connected with a plurality of edges, the plurality of nodes comprises: a plurality of acquirer system nodes comprising at least one node for the acquirer system associated with each of the plurality of transaction records; and a plurality of merchant nodes comprising at least one node for the merchant corresponding to the acquirer system for each of the plurality of transaction records, and the plurality of edges comprises an edge connecting each respective acquirer system node of the plurality of nodes with each merchant node of the plurality of nodes where the merchant corresponding to the acquirer system is a client of the acquirer system; and based on the number of edges connected to the at least one node for the acquirer system for each of the plurality of transaction records, generating the third acquirer risk score.

[0008] In non-limiting embodiments or aspects, generating the first merchant risk score based on the plurality of transaction records and the first risk algorithm comprises: analyzing the plurality of transaction records based on a name entity recognition algorithm configured to recognize the acquirer system associated with each of the plurality of transaction records, the plurality of transaction records comprises a plurality of documents. In non-limiting embodiments or aspects, generating the second merchant risk score based on the plurality of transaction records and the second risk algorithm comprises: determining a time period associated with each of the plurality of transaction records; performing a time-series analysis of the plurality of transaction records to detect a risk associated with abnormal transactions; generating a graph of the plurality of transaction records over a predetermined period of time; determining whether the graph indicates an abnormality by analyzing a pattern of the plurality of transaction records over the predetermined period of time; and generating the second merchant risk score. In non-limiting embodiments or aspects, generating the third merchant risk score based on the plurality of transaction records and a third risk algorithm comprises: generating at least one relational graph based on the plurality of transaction records, the at least one relational graph comprising a plurality of nodes connected with a plurality of edges, the plurality of nodes comprises: a plurality of acquirer system nodes comprising at least one node for the acquirer system associated with each of the plurality of transaction records; and a plurality of merchant nodes comprising at least one node for the merchant corresponding to the acquirer system for each of the plurality of transaction records, and the plurality of edges comprises an edge connecting each respective acquirer system node of the plurality of nodes with each merchant node of the plurality of nodes where the merchant corresponding to the acquirer system is a client of the acquirer system; and based on the number of edges connected to the at least one node for the merchant corresponding to the acquirer system for each of the plurality of transaction records, generating the third merchant risk score.

[0009] In non-limiting embodiments or aspects, generating the final acquirer risk score comprises determining an average of the first acquirer risk score, the second acquirer risk score, the first merchant risk score, and the second merchant risk score. In non-limiting embodiments or aspects, the final acquirer risk score is an average of the first acquirer risk score, the second acquirer risk score, the third acquirer risk score, the first merchant risk score, the second merchant risk score, and the third merchant risk score. In non-limiting embodiments or aspects, the at least one processor is further programmed or configured to: generate a list ranking the acquirer system associated with each of the plurality of transaction records based on the final acquirer risk score.

[0010] According to non-limiting embodiments or aspects, provided is a computer- implemented method comprising: generating, with at least one processor, a first acquirer risk score based on a plurality of transaction records and a first risk algorithm, each transaction record of the plurality of transaction records associated with an acquirer system and at least one merchant corresponding to the acquirer system; generating, with the at least one processor, a first merchant risk score based on the plurality of transaction records and the first risk algorithm; generating, with the at least one processor, a second acquirer risk score based on the plurality of transaction records and a second risk algorithm; generating, with the at least one processor, a second merchant risk score based on the plurality of transaction records and the second risk algorithm; and generating, with the at least one processor, a final acquirer risk score based on the first acquirer risk score, the second acquirer risk score, the first merchant risk score, and the second merchant risk score.

[0011] In non-limiting embodiments or aspects, the method further comprises: generating, with the at least one processor, a third acquirer risk score based on the plurality of transaction records and a third risk algorithm; and generating, with the at least one processor, a third merchant risk score based on the plurality of transaction records and the third risk algorithm, the final acquirer risk score is generated based on the first acquirer risk score, the second acquirer risk score, the third acquirer risk score, the first merchant risk score, the second merchant risk score, and the third merchant risk score. In non-limiting embodiments or aspects, generating the first acquirer risk score based on the plurality of transaction records and the first risk algorithm comprises: analyzing, with the at least one processor, the plurality of transaction records based on a name entity recognition algorithm configured to recognize the acquirer system associated with each of the plurality of transaction records, the plurality of transaction records comprises a plurality of documents; and analyzing, with the at least one processor, a concentration of the plurality of transaction records based on transaction payments for future services to determine a risk associated with future chargeback requests.

[0012] In non-limiting embodiments or aspects, generating the second acquirer risk score based on the plurality of transaction records and the second risk algorithm comprises: determining, with the at least one processor, a time period associated with each of the plurality of transaction records; performing, with the at least one processor, a time-series analysis of the plurality of transaction records based on the time period to detect a risk associated with abnormal transactions; generating, with the at least one processor, a graph of the plurality of transaction records over a predetermined period of time; determining, with the at least one processor, whether the graph indicates an abnormality by analyzing a pattern of the plurality of transaction records over the predetermined period of time; and generating, with the at least one processor, the second acquirer risk score. In non-limiting embodiments or aspects, generating the third acquirer risk score based on the plurality of transaction records and the third risk algorithm comprises: generating, with the at least one processor, at least one relational graph based on the plurality of transaction records, the at least one relational graph comprising a plurality of nodes connected with a plurality of edges, the plurality of nodes comprises: a plurality of acquirer system nodes comprising at least one node for the acquirer system associated with each of the plurality of transaction records; and a plurality of merchant nodes comprising at least one node for the merchant corresponding to the acquirer system for each of the plurality of transaction records, and the plurality of edges comprises an edge connecting each respective acquirer system node of the plurality of nodes with each merchant node of the plurality of nodes where the merchant corresponding to the acquirer system is a client of the acquirer system; and based on the number of edges connected to the at least one node for the acquirer system for each of the plurality of transaction records, generating, with the at least one processor, the third acquirer risk score.

[0013] In non-limiting embodiments or aspects, generating the first merchant risk score based on the plurality of transaction records and the first risk algorithm comprises: analyzing, with the at least one processor, the plurality of transaction records, the plurality of transaction records comprises a plurality of documents, and the first risk algorithm uses name entity recognition and a name matching pipeline to recognize the at least one merchant corresponding to the acquirer system associated with each of the plurality of transaction records. In non-limiting embodiments or aspects, wherein generating the second merchant risk score based on the plurality of transaction records and a second risk algorithm comprises: determining, with the at least one processor, a time period associated with each of the plurality of transaction records; performing, with the at least one processor, a time-series analysis of the plurality of transaction records to detect a risk associated with an abnormal transaction; generating, with the at least one processor, a graph of the plurality of transaction records over a predetermined period of time; determining, with the at least one processor, whether the graph indicates an abnormality by analyzing a pattern of the plurality of transaction records over the predetermined period of time; and generating, with the at least one processor, the second merchant risk score.

[0014] In non-limiting embodiments or aspects, generating the third merchant risk score based on the plurality of transaction records and a third risk algorithm comprises: generating, with the at least one processor, at least one relational graph based on the plurality of transaction records, the at least one relational graph comprising a plurality of nodes connected with a plurality of edges, the plurality of nodes comprises: a plurality of acquirer system nodes comprising at least one node for the acquirer system associated with each of the plurality of transaction records; and a plurality of merchant nodes comprising at least one node for the merchant corresponding to the acquirer system for each of the plurality of transaction records, and the plurality of edges comprises an edge connecting each respective acquirer system node of the plurality of nodes with each merchant node of the plurality of nodes where the merchant corresponding to the acquirer system is a client of the acquirer system; and based on the number of edges connected to the at least one node for the merchant corresponding to the acquirer system for each of the plurality of transaction records, generating, with the at least one processor, the third merchant risk score. In nonlimiting embodiments or aspects, the method further comprises generating with the at least one processor, a list ranking the acquirer system associated with each of the plurality of transaction records based on the final acquirer risk score.

[0015] According to non-limiting embodiments or aspects, provided is a computer program product comprising at least one non-transitory computer-readable medium including program instructions that, when executed by at least one processor, cause the at least one processor to: generate a first acquirer risk score based on a plurality of transaction records and a first risk algorithm, the plurality of transaction records stored in a transaction database, each transaction record of the plurality of transaction records associated with an acquirer system and at least one merchant corresponding to the acquirer system; generate a first merchant risk score based on the plurality of transaction records and the first risk algorithm; generate a second acquirer risk score based on the plurality of transaction records and a second risk algorithm; generate a second merchant risk score based on the plurality of transaction records and the second risk algorithm; and generate a final acquirer risk score based on the first acquirer risk score, the second acquirer risk score, the first merchant risk score, and the second merchant risk score.

[0016] In non-limiting embodiments or aspects, the program instructions further cause the at least one processor to: generate a third acquirer risk score based on the plurality of transaction records and a third risk algorithm; and generate a third merchant risk score based on the plurality of transaction records and the third risk algorithm, the final acquirer risk score is generated based on the first acquirer risk score, the second acquirer risk score, the third acquirer risk score, the first merchant risk score, the second merchant risk score, and the third merchant risk score. In non-limiting embodiments or aspects, wherein generating the first acquirer risk score based on the plurality of transaction records and the first risk algorithm comprises: analyzing the plurality of transaction records based on a name entity recognition algorithm configured to recognize the acquirer system associated with each of the plurality of transaction records, the plurality of transaction records comprises a plurality of documents; and analyzing a concentration of the plurality of transaction records based on transaction payments for future services to determine a risk associated with future chargeback requests. In non-limiting embodiments or aspects, wherein generating the second acquirer risk score based on the plurality of transaction records and the second risk algorithm comprises: determining a time period associated with each of the plurality of transaction records; performing a time-series analysis of the plurality of transaction records based on the time period to detect a risk associated with abnormal transactions; generating a graph of the plurality of transaction records over a predetermined period of time; determining whether the graph indicates an abnormality by analyzing a pattern of the plurality of transaction records over the predetermined period of time; and generating the second acquirer risk score.

[0017] In non-limiting embodiments or aspects, wherein generating the third acquirer risk score based on the plurality of transaction records and the third risk algorithm comprises: generating at least one relational graph based on the plurality of transaction records, the at least one relational graph comprising a plurality of nodes connected with a plurality of edges, the plurality of nodes comprises: a plurality of acquirer system nodes comprising at least one node for the acquirer system associated with each of the plurality of transaction records; and a plurality of merchant nodes comprising at least one node for the merchant corresponding to the acquirer system for each of the plurality of transaction records, and the plurality of edges comprises an edge connecting each respective acquirer system node of the plurality of nodes with each merchant node of the plurality of nodes where the merchant corresponding to the acquirer system is a client of the acquirer system; and based on a number of edges connected to the at least one node for the acquirer system for each of the plurality of transaction records, generating the third acquirer risk score.

[0018] In non-limiting embodiments or aspects, wherein generating the first merchant risk score based on the plurality of transaction records and the first risk algorithm comprises: analyzing the plurality of transaction records based on a name entity recognition algorithm configured to recognize the acquirer system associated with each of the plurality of transaction records, the plurality of transaction records comprises a plurality of documents. In non-limiting embodiments or aspects, wherein generating the second merchant risk score based on the plurality of transaction records and the second risk algorithm comprises: determining a time period associated with each of the plurality of transaction records; performing a time-series analysis of the plurality of transaction records to detect a risk associated with abnormal transactions; generating a graph of the plurality of transaction records over a predetermined period of time; determining whether the graph indicates an abnormality by analyzing a pattern of the plurality of transaction records over the predetermined period of time; and generating the second merchant risk score.

[0019] In non-limiting embodiments or aspects, wherein generating the third merchant risk score based on the plurality of transaction records and a third risk algorithm comprises: generating at least one relational graph based on the plurality of transaction records, the at least one relational graph comprising a plurality of nodes connected with a plurality of edges, the plurality of nodes comprises: a plurality of acquirer system nodes comprising at least one node for the acquirer system associated with each of the plurality of transaction records; and a plurality of merchant nodes comprising at least one node for the merchant corresponding to the acquirer system for each of the plurality of transaction records, and the plurality of edges comprises an edge connecting each respective acquirer system node of the plurality of nodes with each merchant node of the plurality of nodes where the merchant corresponding to the acquirer system is a client of the acquirer system; and based on a number of edges connected to the at least one node for the merchant corresponding to the acquirer system for each of the plurality of transaction records, generating the third merchant risk score.

[0020] In non-limiting embodiments or aspects, wherein generating the final acquirer risk score comprises determining an average of the first acquirer risk score, the second acquirer risk score, the first merchant risk score, and the second merchant risk score. In non-limiting embodiments or aspects, the final acquirer risk score is an average of the first acquirer risk score, the second acquirer risk score, the third acquirer risk score, the first merchant risk score, the second merchant risk score, and the third merchant risk score. In non-limiting embodiments or aspects, the program instructions further cause the at least one processor to: generate a list ranking the acquirer system associated with each of the plurality of transaction records based on the final acquirer risk score.

[0021] Further embodiments or aspects are set forth in the following numbered clauses: [0022] Clause 1 : A system comprising: a transaction database comprising a plurality of transaction records, each transaction record associated with an acquirer system and at least one merchant corresponding to the acquirer system; at least one processor in communication with the transaction database, the at least one processor programmed or configured to: generate a first acquirer risk score based on the plurality of transaction records and a first risk algorithm; generate a first merchant risk score based on the plurality of transaction records and the first risk algorithm; generate a second acquirer risk score based on the plurality of transaction records and a second risk algorithm; generate a second merchant risk score based on the plurality of transaction records and the second risk algorithm; and generate a final acquirer risk score based on the first acquirer risk score, the second acquirer risk score, the first merchant risk score, and the second merchant risk score.

[0023] Clause 2: The system of clause 1 , wherein the at least one processor is further programmed or configured to: generate a third acquirer risk score based on the plurality of transaction records and a third risk algorithm; and generate a third merchant risk score based on the plurality of transaction records and the third risk algorithm, wherein the final acquirer risk score is generated based on the first acquirer risk score, the second acquirer risk score, the third acquirer risk score, the first merchant risk score, the second merchant risk score, and the third merchant risk score.

[0024] Clause 3: The system of clauses 1 or 2, wherein generating the first acquirer risk score based on the plurality of transaction records and the first risk algorithm comprises: analyzing the plurality of transaction records based on a name entity recognition algorithm configured to recognize the acquirer system associated with each of the plurality of transaction records, wherein the plurality of transaction records comprises a plurality of documents; and analyzing a concentration of the plurality of transaction records based on transaction payments for future services to determine a risk associated with future chargeback requests.

[0025] Clause 4: The system of any of clauses 1 -3, wherein generating the second acquirer risk score based on the plurality of transaction records and the second risk algorithm comprises: determining a time period associated with each of the plurality of transaction records; performing a time-series analysis of the plurality of transaction records based on the time period to detect a risk associated with abnormal transactions; generating a graph of the plurality of transaction records over a predetermined period of time; determining whether the graph indicates an abnormality by analyzing a pattern of the plurality of transaction records over the predetermined period of time; and generating the second acquirer risk score.

[0026] Clause 5: The system of any of clauses 1 -4, wherein generating the third acquirer risk score based on the plurality of transaction records and the third risk algorithm comprises: generating at least one relational graph based on the plurality of transaction records, the at least one relational graph comprising a plurality of nodes connected with a plurality of edges, wherein the plurality of nodes comprises: a plurality of acquirer system nodes comprising at least one node for the acquirer system associated with each of the plurality of transaction records; and a plurality of merchant nodes comprising at least one node for the merchant corresponding to the acquirer system for each of the plurality of transaction records, and wherein the plurality of edges comprises an edge connecting each respective acquirer system node of the plurality of nodes with each merchant node of the plurality of nodes where the merchant corresponding to the acquirer system is a client of the acquirer system; and based on the number of edges connected to the at least one node for the acquirer system for each of the plurality of transaction records, generating the third acquirer risk score.

[0027] Clause 6: The system of any of clauses 1 -5, wherein generating the first merchant risk score based on the plurality of transaction records and the first risk algorithm comprises: analyzing the plurality of transaction records based on a name entity recognition algorithm configured to recognize the acquirer system associated with each of the plurality of transaction records, wherein the plurality of transaction records comprises a plurality of documents.

[0028] Clause 7: The system of any of clauses 1 -6, wherein generating the second merchant risk score based on the plurality of transaction records and the second risk algorithm comprises: determining a time period associated with each of the plurality of transaction records; performing a time-series analysis of the plurality of transaction records to detect a risk associated with abnormal transactions; generating a graph of the plurality of transaction records over a predetermined period of time; determining whether the graph indicates an abnormality by analyzing a pattern of the plurality of transaction records over the predetermined period of time; and generating the second merchant risk score.

[0029] Clause 8: The system of any of clauses 1 -7, wherein generating the third merchant risk score based on the plurality of transaction records and a third risk algorithm comprises: generating at least one relational graph based on the plurality of transaction records, the at least one relational graph comprising a plurality of nodes connected with a plurality of edges, wherein the plurality of nodes comprises: a plurality of acquirer system nodes comprising at least one node for the acquirer system associated with each of the plurality of transaction records; and a plurality of merchant nodes comprising at least one node for the merchant corresponding to the acquirer system for each of the plurality of transaction records, and wherein the plurality of edges comprises an edge connecting each respective acquirer system node of the plurality of nodes with each merchant node of the plurality of nodes where the merchant corresponding to the acquirer system is a client of the acquirer system; and based on the number of edges connected to the at least one node for the merchant corresponding to the acquirer system for each of the plurality of transaction records, generating the third merchant risk score.

[0030] Clause 9: The system of any of clauses 1 -8, wherein generating the final acquirer risk score comprises determining an average of the first acquirer risk score, the second acquirer risk score, the first merchant risk score, and the second merchant risk score.

[0031] Clause 10: The system of any of clauses 1 -9, wherein the final acquirer risk score is an average of the first acquirer risk score, the second acquirer risk score, the third acquirer risk score, the first merchant risk score, the second merchant risk score, and the third merchant risk score.

[0032] Clause 1 1 : The system of any of clauses 1 -10, wherein the at least one processor is further programmed or configured to: generate a list ranking the acquirer system associated with each of the plurality of transaction records based on the final acquirer risk score.

[0033] Clause 12: A computer-implemented method comprising: generating, with at least one processor, a first acquirer risk score based on a plurality of transaction records and a first risk algorithm, each transaction record of the plurality of transaction records associated with an acquirer system and at least one merchant corresponding to the acquirer system; generating, with the at least one processor, a first merchant risk score based on the plurality of transaction records and the first risk algorithm; generating, with the at least one processor, a second acquirer risk score based on the plurality of transaction records and a second risk algorithm; generating, with the at least one processor, a second merchant risk score based on the plurality of transaction records and the second risk algorithm; and generating, with the at least one processor, a final acquirer risk score based on the first acquirer risk score, the second acquirer risk score, the first merchant risk score, and the second merchant risk score.

[0034] Clause 13: The method of clause 12, further comprising: generating, with the at least one processor, a third acquirer risk score based on the plurality of transaction records and a third risk algorithm; and generating, with the at least one processor, a third merchant risk score based on the plurality of transaction records and the third risk algorithm, wherein the final acquirer risk score is generated based on the first acquirer risk score, the second acquirer risk score, the third acquirer risk score, the first merchant risk score, the second merchant risk score, and the third merchant risk score.

[0035] Clause 14: The method of clauses 12 or 13, wherein generating the first acquirer risk score based on the plurality of transaction records and the first risk algorithm comprises: analyzing, with the at least one processor, the plurality of transaction records based on a name entity recognition algorithm configured to recognize the acquirer system associated with each of the plurality of transaction records, wherein the plurality of transaction records comprises a plurality of documents; and analyzing, with the at least one processor, a concentration of the plurality of transaction records based on transaction payments for future services to determine a risk associated with future chargeback requests.

[0036] Clause 15: The method of any of clauses 12-14, wherein generating the second acquirer risk score based on the plurality of transaction records and the second risk algorithm comprises: determining, with the at least one processor, a time period associated with each of the plurality of transaction records; performing, with the at least one processor, a time-series analysis of the plurality of transaction records based on the time period to detect a risk associated with abnormal transactions; generating, with the at least one processor, a graph of the plurality of transaction records over a predetermined period of time; determining, with the at least one processor, whether the graph indicates an abnormality by analyzing a pattern of the plurality of transaction records over the predetermined period of time; and generating, with the at least one processor, the second acquirer risk score.

[0037] Clause 16: The method of any of clauses 12-15, wherein generating the third acquirer risk score based on the plurality of transaction records and the third risk algorithm comprises: generating, with the at least one processor, at least one relational graph based on the plurality of transaction records, the at least one relational graph comprising a plurality of nodes connected with a plurality of edges, wherein the plurality of nodes comprises: a plurality of acquirer system nodes comprising at least one node for the acquirer system associated with each of the plurality of transaction records; and a plurality of merchant nodes comprising at least one node for the merchant corresponding to the acquirer system for each of the plurality of transaction records, and wherein the plurality of edges comprises an edge connecting each respective acquirer system node of the plurality of nodes with each merchant node of the plurality of nodes where the merchant corresponding to the acquirer system is a client of the acquirer system; and based on the number of edges connected to the at least one node for the acquirer system for each of the plurality of transaction records, generating, with the at least one processor, the third acquirer risk score.

[0038] Clause 17: The method of any of clauses 12-16, wherein generating the first merchant risk score based on the plurality of transaction records and the first risk algorithm comprises: analyzing, with the at least one processor, the plurality of transaction records, wherein the plurality of transaction records comprises a plurality of documents, and wherein the first risk algorithm uses name entity recognition and a name matching pipeline to recognize the at least one merchant corresponding to the acquirer system associated with each of the plurality of transaction records.

[0039] Clause 18: The method of any of clauses 12-17, wherein generating the second merchant risk score based on the plurality of transaction records and a second risk algorithm comprises: determining, with the at least one processor, a time period associated with each of the plurality of transaction records; performing, with the at least one processor, a time-series analysis of the plurality of transaction records to detect a risk associated with an abnormal transaction; generating, with the at least one processor, a graph of the plurality of transaction records over a predetermined period of time; determining, with the at least one processor, whether the graph indicates an abnormality by analyzing a pattern of the plurality of transaction records over the predetermined period of time; and generating, with the at least one processor, the second merchant risk score.

[0040] Clause 19: The method of any of clauses 12-18, wherein generating the third merchant risk score based on the plurality of transaction records and a third risk algorithm comprises: generating, with the at least one processor, at least one relational graph based on the plurality of transaction records, the at least one relational graph comprising a plurality of nodes connected with a plurality of edges, wherein the plurality of nodes comprises: a plurality of acquirer system nodes comprising at least one node for the acquirer system associated with each of the plurality of transaction records; and a plurality of merchant nodes comprising at least one node for the merchant corresponding to the acquirer system for each of the plurality of transaction records, and wherein the plurality of edges comprises an edge connecting each respective acquirer system node of the plurality of nodes with each merchant node of the plurality of nodes where the merchant corresponding to the acquirer system is a client of the acquirer system; and based on the number of edges connected to the at least one node for the merchant corresponding to the acquirer system for each of the plurality of transaction records, generating, with the at least one processor, the third merchant risk score.

[0041] Clause 20: The method of any of clauses 12-19 further comprising: generating, with the at least one processor, a list ranking the acquirer system associated with each of the plurality of transaction records based on the final acquirer risk score.

[0042] Clause 21 : A computer program product comprising at least one non- transitory computer-readable medium including program instructions that, when executed by at least one processor, cause the at least one processor to: generate a first acquirer risk score based on a plurality of transaction records and a first risk algorithm, the plurality of transaction records stored in a transaction database, each transaction record of the plurality of transaction records associated with an acquirer system and at least one merchant corresponding to the acquirer system; generate a first merchant risk score based on the plurality of transaction records and the first risk algorithm; generate a second acquirer risk score based on the plurality of transaction records and a second risk algorithm; generate a second merchant risk score based on the plurality of transaction records and the second risk algorithm; and generate a final acquirer risk score based on the first acquirer risk score, the second acquirer risk score, the first merchant risk score, and the second merchant risk score.

[0043] Clause 22: The computer program product of clause 21 , wherein the program instructions further cause the at least one processor to: generate a third acquirer risk score based on the plurality of transaction records and a third risk algorithm; and generate a third merchant risk score based on the plurality of transaction records and the third risk algorithm, wherein the final acquirer risk score is generated based on the first acquirer risk score, the second acquirer risk score, the third acquirer risk score, the first merchant risk score, the second merchant risk score, and the third merchant risk score.

[0044] Clause 23: The computer program product of clauses 21 or 22, wherein generating the first acquirer risk score based on the plurality of transaction records and the first risk algorithm comprises: analyzing the plurality of transaction records based on a name entity recognition algorithm configured to recognize the acquirer system associated with each of the plurality of transaction records, wherein the plurality of transaction records comprises a plurality of documents; and analyzing a concentration of the plurality of transaction records based on transaction payments for future services to determine a risk associated with future chargeback requests.

[0045] Clause 24: The computer program product of any of clauses 21 -23, wherein generating the second acquirer risk score based on the plurality of transaction records and the second risk algorithm comprises: determining a time period associated with each of the plurality of transaction records; performing a time-series analysis of the plurality of transaction records based on the time period to detect a risk associated with abnormal transactions; generating a graph of the plurality of transaction records over a predetermined period of time; determining whether the graph indicates an abnormality by analyzing a pattern of the plurality of transaction records over the predetermined period of time; and generating the second acquirer risk score.

[0046] Clause 25: The computer program product of any of clauses 21 -24, wherein generating the third acquirer risk score based on the plurality of transaction records and the third risk algorithm comprises: generating at least one relational graph based on the plurality of transaction records, the at least one relational graph comprising a plurality of nodes connected with a plurality of edges, wherein the plurality of nodes comprises: a plurality of acquirer system nodes comprising at least one node for the acquirer system associated with each of the plurality of transaction records; and a plurality of merchant nodes comprising at least one node for the merchant corresponding to the acquirer system for each of the plurality of transaction records, and wherein the plurality of edges comprises an edge connecting each respective acquirer system node of the plurality of nodes with each merchant node of the plurality of nodes where the merchant corresponding to the acquirer system is a client of the acquirer system; and based on a number of edges connected to the at least one node for the acquirer system for each of the plurality of transaction records, generating the third acquirer risk score.

[0047] Clause 26: The computer program product of any of clauses 21 -25, wherein generating the first merchant risk score based on the plurality of transaction records and the first risk algorithm comprises: analyzing the plurality of transaction records based on a name entity recognition algorithm configured to recognize the acquirer system associated with each of the plurality of transaction records, wherein the plurality of transaction records comprises a plurality of documents.

[0048] Clause 27: The computer program product of any of clauses 21 -26, wherein generating the second merchant risk score based on the plurality of transaction records and the second risk algorithm comprises: determining a time period associated with each of the plurality of transaction records; performing a time-series analysis of the plurality of transaction records to detect a risk associated with abnormal transactions; generating a graph of the plurality of transaction records over a predetermined period of time; determining whether the graph indicates an abnormality by analyzing a pattern of the plurality of transaction records over the predetermined period of time; and generating the second merchant risk score.

[0049] Clause 28: The computer program product of any of clauses 21 -27, wherein generating the third merchant risk score based on the plurality of transaction records and a third risk algorithm comprises: generating at least one relational graph based on the plurality of transaction records, the at least one relational graph comprising a plurality of nodes connected with a plurality of edges, wherein the plurality of nodes comprises: a plurality of acquirer system nodes comprising at least one node for the acquirer system associated with each of the plurality of transaction records; and a plurality of merchant nodes comprising at least one node for the merchant corresponding to the acquirer system for each of the plurality of transaction records, and wherein the plurality of edges comprises an edge connecting each respective acquirer system node of the plurality of nodes with each merchant node of the plurality of nodes where the merchant corresponding to the acquirer system is a client of the acquirer system; and based on a number of edges connected to the at least one node for the merchant corresponding to the acquirer system for each of the plurality of transaction records, generating the third merchant risk score.

[0050] Clause 29: The computer program product of any of clauses 21 -28, wherein generating the final acquirer risk score comprises determining an average of the first acquirer risk score, the second acquirer risk score, the first merchant risk score, and the second merchant risk score.

[0051] Clause 30: The computer program product of any of clauses 21 -29, wherein the final acquirer risk score is an average of the first acquirer risk score, the second acquirer risk score, the third acquirer risk score, the first merchant risk score, the second merchant risk score, and the third merchant risk score.

[0052] Clause 31 : The computer program product of any of clauses 21 -30, wherein the program instructions further cause the at least one processor to: generate a list ranking the acquirer system associated with each of the plurality of transaction records based on the final acquirer risk score.

[0053] These and other features and characteristics of the presently disclosed subject matter, as well as the methods of operation and functions of the related elements of structures and the combination of parts and economies of manufacture, will become more apparent upon consideration of the following description and the appended claims with reference to the accompanying drawings, all of which form a part of this specification, wherein like reference numerals designate corresponding parts in the various figures. It is to be expressly understood, however, that the drawings are for the purpose of illustration and description only and are not intended as a definition of the limits of the disclosed subject matter. As used in the specification and the claims, the singular form of “a,” “an,” and “the” include plural referents unless the context clearly dictates otherwise.

BRIEF DESCRIPTION OF THE DRAWINGS

[0054] Additional advantages and details of the disclosed subject matter are explained in greater detail below with reference to the exemplary embodiments or aspects that are illustrated in the accompanying figures, in which:

[0055] FIG. 1 is a flow diagram of a system for monitoring acquirer credit settlement risk according to non-limiting embodiments or aspects;

[0056] FIG. 2 is a diagram of a process for monitoring acquirer credit settlement risk according to non-limiting embodiments or aspects;

[0057] FIG. 3 is a flow diagram of a process for monitoring acquirer credit settlement risk according to non-limiting embodiments or aspects;

[0058] FIG. 4 is a flow diagram of a process for monitoring acquirer credit settlement risk according to non-limiting embodiments or aspects; [0059] FIG. 5 is a flow diagram of a process for monitoring acquirer credit settlement risk according to non-limiting embodiments or aspects;

[0060] FIG. 6 is a flow diagram of a process for monitoring acquirer credit settlement risk according to non-limiting embodiments or aspects;

[0061] FIG. 7 is a flow diagram of a process for monitoring acquirer credit settlement risk according to non-limiting embodiments or aspects;

[0062] FIG. 8 is a flow diagram of a process for monitoring acquirer credit settlement risk according to non-limiting embodiments or aspects;

[0063] FIG. 9 is a schematic diagram of a system for monitoring acquirer credit settlement risk according to non-limiting embodiments or aspects;

[0064] FIG. 10 is a relational graph according to non-limiting embodiments or aspects associated with the process shown in FIG. 2; and

[0065] FIG. 11 is a diagram of example components of a device.

DESCRIPTION

[0066] For purposes of the description hereinafter, the terms “end,” “upper,” “lower,” “right,” “left,” “vertical,” “horizontal,” “top,” “bottom,” “lateral,” “longitudinal,” and derivatives thereof shall relate to the disclosed subject matter as it is oriented in the drawing figures. However, it is to be understood that the disclosed subject matter may assume various alternative variations and step sequences, except where expressly specified to the contrary. It is also to be understood that the specific devices and processes illustrated in the attached drawings, and described in the following specification, are simply exemplary embodiments or aspects of the disclosed subject matter. Hence, specific dimensions and other physical characteristics related to the embodiments or aspects disclosed herein are not to be considered as limiting unless otherwise indicated.

[0067] No aspect, component, element, structure, act, step, function, instruction, and/or the like used herein should be construed as critical or essential unless explicitly described as such. Also, as used herein, the articles “a” and “an” are intended to include one or more items and may be used interchangeably with “one or more” and “at least one.” Furthermore, as used herein, the term “set” is intended to include one or more items (e.g., related items, unrelated items, a combination of related and unrelated items, and/or the like) and may be used interchangeably with “one or more” or “at least one.” Where only one item is intended, the term “one” or similar language is used. Also, as used herein, the terms “has,” “have,” “having,” or the like are intended to be open-ended terms. Further, the phrase “based on” is intended to mean “based at least partially on” unless explicitly stated otherwise.

[0068] As used herein, the terms “communication” and “communicate” may refer to the reception, receipt, transmission, transfer, provision, and/or the like of information (e.g., data, signals, messages, instructions, commands, and/or the like). For one unit (e.g., a device, a system, a component of a device or system, combinations thereof, and/or the like) to be in communication with another unit means that the one unit is able to directly or indirectly receive information from and/or transmit information to the other unit. This may refer to a direct or indirect connection (e.g., a direct communication connection, an indirect communication connection, and/or the like) that is wired and/or wireless in nature. Additionally, two units may be in communication with each other even though the information transmitted may be modified, processed, relayed, and/or routed between the first and second unit. For example, a first unit may be in communication with a second unit even though the first unit passively receives information and does not actively transmit information to the second unit. As another example, a first unit may be in communication with a second unit if at least one intermediary unit (e.g., a third unit located between the first unit and the second unit) processes information received from the first unit and communicates the processed information to the second unit. In some non-limiting embodiments or aspects, a message may refer to a network packet (e.g., a data packet and/or the like) that includes data. It will be appreciated that numerous other arrangements are possible. [0069] As used herein, the terms “issuer institution,” “portable financial device issuer,” “issuer,” or “issuer bank” may refer to one or more entities that provide accounts to customers for conducting transactions (e.g., payment transactions), such as initiating credit and/or debit payments. For example, an issuer institution may provide an account identifier, such as a primary account number (PAN), to a customer that uniquely identifies one or more accounts associated with that customer. The account identifier may be embodied on a portable financial device, such as a physical financial instrument, e.g., a payment card, and/or may be electronic and used for electronic payments. The terms “issuer institution” and “issuer institution system” may also refer to one or more computer systems operated by or on behalf of an issuer institution, such as a server computer executing one or more software applications. For example, an issuer institution system may include one or more authorization servers for authorizing a transaction. [0070] As used herein, the term “account identifier” may include one or more types of identifiers associated with a user account (e.g., a PAN, a card number, a payment card number, a payment token, and/or the like). In some non-limiting embodiments or aspects, an issuer institution may provide an account identifier (e.g., a PAN, a payment token, and/or the like) to a user that uniquely identifies one or more accounts associated with that user. The account identifier may be embodied on a physical financial instrument (e.g., a portable financial instrument, a payment card, a credit card, a debit card, and/or the like) and/or may be electronic information communicated to the user that the user may use for electronic payments. In some non-limiting embodiments or aspects, the account identifier may be an original account identifier, where the original account identifier was provided to a user at the creation of the account associated with the account identifier. In some non-limiting embodiments or aspects, the account identifier may be an account identifier (e.g., a supplemental account identifier) that is provided to a user after the original account identifier was provided to the user. For example, if the original account identifier is forgotten, stolen, and/or the like, a supplemental account identifier may be provided to the user. In some non-limiting embodiments or aspects, an account identifier may be directly or indirectly associated with an issuer institution such that an account identifier may be a payment token that maps to a PAN or other type of identifier. Account identifiers may be alphanumeric, any combination of characters and/or symbols, and/or the like. An issuer institution may be associated with a bank identification number (BIN) that uniquely identifies the issuer institution.

[0071] As used herein, the terms “payment token” or “token” may refer to an identifier that is used as a substitute or replacement identifier for an account identifier, such as a PAN. Tokens may be associated with a PAN or other account identifiers in one or more data structures (e.g., one or more databases and/or the like) such that they can be used to conduct a transaction (e.g., a payment transaction) without directly using the account identifier, such as a PAN. In some examples, an account identifier, such as a PAN, may be associated with a plurality of tokens for different individuals, different uses, and/or different purposes. For example, a payment token may include a series of numeric and/or alphanumeric characters that may be used as a substitute for an original account identifier. For example, a payment token “4900 0000 0000 0001 ” may be used in place of a PAN “4147 0900 0000 1234.” In some non-limiting embodiments or aspects, a payment token may be “format preserving” and may have a numeric format that conforms to the account identifiers used in existing payment processing networks (e.g., ISO 8583 financial transaction message format). In some non-limiting embodiments or aspects, a payment token may be used in place of a PAN to initiate, authorize, settle, or resolve a payment transaction or represent the original credential in other systems where the original credential would typically be provided. In some non-limiting embodiments or aspects, a token value may be generated such that the recovery of the original PAN or other account identifier from the token value may not be computationally derived (e.g., with a one-way hash or other cryptographic function). Further, in some non-limiting embodiments or aspects, the token format may be configured to allow the entity receiving the payment token to identify it as a payment token and recognize the entity that issued the token.

[0072] As used herein, the term “token requestor” may refer to an entity that is seeking to implement tokenization according to embodiments or aspects of the presently disclosed subject matter. For example, the token requestor may initiate a request that a PAN be tokenized by submitting a token request message to a token service provider. Additionally or alternatively, a token requestor may no longer need to store a PAN associated with a token once the requestor has received the payment token in response to a token request message. In some non-limiting embodiments or aspects, the requestor may be an application, a device, a process, or a system that is configured to perform actions associated with tokens. For example, a requestor may request registration with a network token system, request token generation, token activation, token de-activation, token exchange, other token lifecycle management related processes, and/or any other token related processes. In some non-limiting embodiments or aspects, a token requestor may interface with a network token system through any suitable communication network and/or protocol (e.g., using HTTPS, SOAP, and/or an XML interface among others). For example, a token requestor may include card-on-file merchants, acquirers, acquirer processors, payment gateways acting on behalf of merchants, payment enablers (e.g., original equipment manufacturers, mobile network operators, and/or the like), digital wallet providers, issuers, third-party wallet providers, payment processing networks, and/or the like. In some non-limiting embodiments or aspects, a token requestor may request tokens for multiple domains and/or channels. Additionally or alternatively, a token requestor may be registered and identified uniquely by the token service provider within the tokenization ecosystem. For example, during token requestor registration, the token service provider may formally process a token requestor’s application to participate in the token service system. In some non-limiting embodiments or aspects, the token service provider may collect information pertaining to the nature of the requestor and relevant use of tokens to validate and formally approve the token requestor and establish appropriate domain restriction controls. Additionally or alternatively, successfully registered token requestors may be assigned a token requestor identifier that may also be entered and maintained within the token vault. In some non-limiting embodiments or aspects, token requestor identifiers may be revoked and/or token requestors may be assigned new token requestor identifiers. In some non-limiting embodiments or aspects, this information may be subject to reporting and audit by the token service provider.

[0073] As used herein, the term a “token service provider” may refer to an entity including one or more server computers in a token service system that generates, processes, and maintains payment tokens. For example, the token service provider may include or be in communication with a token vault where the generated tokens are stored. Additionally or alternatively, the token vault may maintain one-to-one mapping between a token and a PAN represented by the token. In some non-limiting embodiments or aspects, the token service provider may have the ability to set aside licensed bank identification numbers (BINs) as token BINs to issue tokens for the PANs that may be submitted to the token service provider. In some non-limiting embodiments or aspects, various entities of a tokenization ecosystem may assume the roles of the token service provider. For example, payment networks and issuers or their agents may become the token service provider by implementing the token services according to non-limiting embodiments or aspects of the presently disclosed subject matter. Additionally or alternatively, a token service provider may provide reports or data output to reporting tools regarding approved, pending, or declined token requests, including any assigned token requestor ID. The token service provider may provide data output related to token-based transactions to reporting tools and applications and present the token and/or PAN as appropriate in the reporting output. In some non-limiting embodiments or aspects, the EMVCo standards organization may publish specifications defining how tokenized systems may operate. For example, such specifications may be informative, but they are not intended to be limiting upon any of the presently disclosed subject matter. [0074] As used herein, the term “token vault” may refer to a repository that maintains established token-to-PAN mappings. For example, the token vault may also maintain other attributes of the token requestor that may be determined at the time of registration and/or that may be used by the token service provider to apply domain restrictions or other controls during transaction processing. In some non-limiting embodiments or aspects, the token vault may be a part of a token service system. For example, the token vault may be provided as a part of the token service provider. Additionally or alternatively, the token vault may be a remote repository accessible by the token service provider. In some non-limiting embodiments or aspects, token vaults, due to the sensitive nature of the data mappings that are stored and managed therein, may be protected by strong underlying physical and logical security. Additionally or alternatively, a token vault may be operated by any suitable entity, including a payment network, an issuer, clearing houses, other financial institutions, transaction service providers, and/or the like.

[0075] As used herein, the term “merchant” may refer to one or more entities (e.g., operators of retail businesses that provide goods and/or services, and/or access to goods and/or services, to a user (e.g., a customer, a consumer, a customer of the merchant, and/or the like) based on a transaction (e.g., a payment transaction)). As used herein, the term “merchant system” may refer to one or more computer systems operated by or on behalf of a merchant, such as a server computer executing one or more software applications. As used herein, the term “product” may refer to one or more goods and/or services offered by a merchant.

[0076] As used herein, the term “point-of-sale (POS) device” may refer to one or more devices, which may be used by a merchant to initiate transactions (e.g., a payment transaction), engage in transactions, and/or process transactions. For example, a POS device may include one or more computers, peripheral devices, card readers, near-field communication (NFC) receivers, radio frequency identification (RFID) receivers, and/or other contactless transceivers or receivers, contact-based receivers, payment terminals, computers, servers, input devices, and/or the like. As used herein, the term “point-of-sale (POS) system” may refer to one or more computers and/or peripheral devices used by a merchant to conduct a transaction. For example, a POS system may include one or more POS devices and/or other like devices that may be used to conduct a payment transaction. A POS system (e.g., a merchant POS system) may also include one or more server computers programmed or configured to process online payment transactions through webpages, mobile applications, and/or the like.

[0077] As used herein, the term “transaction service provider” may refer to an entity that receives transaction authorization requests from merchants or other entities and provides guarantees of payment, in some cases through an agreement between the transaction service provider and the issuer institution. In some non-limiting embodiments or aspects, a transaction service provider may include a credit card company, a debit card company, and/or the like. As used herein, the term “transaction service provider system” may also refer to one or more computer systems operated by or on behalf of a transaction service provider, such as a transaction processing server executing one or more software applications. A transaction processing server may include one or more processors and, in some non-limiting embodiments or aspects, may be operated by or on behalf of a transaction service provider.

[0078] As used herein, the term “acquirer” may refer to an entity licensed by the transaction service provider and approved by the transaction service provider to originate transactions (e.g., payment transactions) using a portable financial device associated with the transaction service provider. As used herein, the term “acquirer system” may also refer to one or more computer systems, computer devices, and/or the like operated by or on behalf of an acquirer. The transactions may include payment transactions (e.g., purchases, original credit transactions (OCTs), account funding transactions (AFTs), and/or the like). In some non-limiting embodiments or aspects, the acquirer may be authorized by the transaction service provider to assign merchant or service providers to originate transactions using a portable financial device of the transaction service provider. The acquirer may contract with payment facilitators to enable the payment facilitators to sponsor merchants. The acquirer may monitor compliance of the payment facilitators in accordance with regulations of the transaction service provider. The acquirer may conduct due diligence of the payment facilitators and ensure that proper due diligence occurs before signing a sponsored merchant. The acquirer may be liable for all transaction service provider programs that the acquirer operates or sponsors. The acquirer may be responsible for the acts of the acquirer’s payment facilitators, merchants that are sponsored by an acquirer’s payment facilitators, and/or the like. In some non-limiting embodiments or aspects, an acquirer may be a financial institution, such as a bank. [0079] As used herein, the term “portable financial device” may refer to a payment card (e.g., a credit or debit card), a gift card, a smartcard, smart media, a payroll card, a healthcare card, a wrist band, a machine-readable medium containing account information, a keychain device or fob, an RFID transponder, a retailer discount or loyalty card, a cellular phone, an electronic wallet mobile application, a personal digital assistant (PDA), a pager, a security card, a computer, an access card, a wireless terminal, a transponder, and/or the like. In some non-limiting embodiments or aspects, the portable financial device may include volatile or non-volatile memory to store information (e.g., an account identifier, a name of the account holder, and/or the like). [0080] As used herein, the term “payment gateway” may refer to an entity and/or a payment processing system operated by or on behalf of such an entity (e.g., a merchant service provider, a payment service provider, a payment facilitator, a payment facilitator that contracts with an acquirer, a payment aggregator, and/or the like), which provides payment services (e.g., transaction service provider payment services, payment processing services, and/or the like) to one or more merchants. The payment services may be associated with the use of portable financial devices managed by a transaction service provider. As used herein, the term “payment gateway system” may refer to one or more computer systems, computer devices, servers, groups of servers, and/or the like operated by or on behalf of a payment gateway and/or to a payment gateway itself. As used herein, the term “payment gateway mobile application” may refer to one or more electronic devices and/or one or more software applications configured to provide payment services for transactions (e.g., payment transactions, electronic payment transactions, and/or the like).

[0081] As used herein, the terms “client” and “client device” may refer to one or more client-side devices or systems (e.g., remote from a transaction service provider) used to initiate or facilitate a transaction (e.g., a payment transaction). As an example, a “client device” may refer to one or more POS devices used by a merchant, one or more acquirer host computers used by an acquirer, one or more mobile devices used by a user, and/or the like. In some non-limiting embodiments or aspects, a client device may be an electronic device configured to communicate with one or more networks and initiate or facilitate transactions. For example, a client device may include one or more computers, portable computers, laptop computers, tablet computers, mobile devices, cellular phones, wearable devices (e.g., watches, glasses, lenses, clothing, and/or the like), PDAs, and/or the like. Moreover, a “client” may also refer to an entity (e.g., a merchant, an acquirer, and/or the like) that owns, utilizes, and/or operates a client device for initiating transactions (e.g., for initiating transactions with a transaction service provider).

[0082] As used herein, the term “server” may refer to one or more computing devices (e.g., processors, storage devices, similar computer components, and/or the like) that communicate with client devices and/or other computing devices over a network (e.g., a public network, the Internet, a private network, and/or the like) and, in some examples, facilitate communication among other servers and/or client devices. It will be appreciated that various other arrangements are possible. As used herein, the term “system” may refer to one or more computing devices or combinations of computing devices (e.g., processors, servers, client devices, software applications, components of such, and/or the like). Reference to “a device,” “a server,” “a processor,” and/or the like, as used herein, may refer to a previously-recited device, server, or processor that is recited as performing a previous step or function, a different server or processor, and/or a combination of servers and/or processors. For example, as used in the specification and the claims, a first server or a first processor that is recited as performing a first step or a first function may refer to the same or different server or the same or different processor recited as performing a second step or a second function.

[0083] Non-limiting embodiments or aspects of the disclosed subject matter are directed to systems and methods for monitoring acquirer risk, including, but not limited to, a framework for monitoring acquirer credit settlement risk. For example, nonlimiting embodiments or aspects of the disclosed subject matter provide a deeplearning-based framework for assessing and monitoring acquirer risk. Non-limiting embodiments or aspects provide for the evaluation of various types of data sources and data formats (e.g., simple numerical data, categorical data, sequential data, textual documents, and/or the like). Non-limiting embodiments or aspects provide for the utilization of various models (e.g., direct assessment, temporal assessment, peer assessment, and/or the like), each model handling the data source in the format that is best suited for the data source to guarantee the accuracy of the final output. Nonlimiting embodiments or aspects provide a modularized framework which, given different data availability, can be adjusted by adding, removing, and/or executing certain models. [0084] For the purpose of illustration, in the following description, while the presently disclosed subject matter is described with respect to methods and systems for monitoring acquirer risk, e.g., a framework for monitoring acquirer credit settlement risk, one skilled in the art will recognize that the disclosed subject matter is not limited to the illustrative embodiments or aspects. For example, the methods and systems described herein may be used with a wide variety of settings, including any setting suitable for using such a framework for monitoring acquirer risk.

[0085] Referring now to FIG. 1 , a system 100 for determining an acquirer risk score based on transaction data is shown according to a non-limiting embodiment. The system 100 shown in FIG. 1 includes issuer system 102, transaction processing system 104, transaction database 106, acquirer system 108, merchant system(s) 1 10, scoring engine 1 12, output 1 14, and/or computing device 1 16. In some non-limiting embodiments or aspects, issuer system 102 may include one or more computing devices capable of receiving information from and/or communicating information to transaction processing system 104. For example, issuer system 102 may include a computing device 1 16, such as a server (e.g., an issuer server), a group of servers, and/or other like devices.

[0086] In some non-limiting embodiments or aspects, transaction processing system 104 may include one or more computing devices capable of receiving information from and/or communicating information to issuer system 102, transaction database 106, and acquirer system 108. For example, transaction processing system 104 may include a computing device 1 16, such as a server (e.g., transaction processing server), a group of servers, and/or other like devices. The transaction processing system 104 includes a scoring engine 1 12. In some non-limiting embodiments or aspects, the transaction processing system 104 is in communication with a transaction database 106 which may include one or more devices capable of receiving information from and/or communicating information to transaction processing system 104. For example, transaction database 106 may include a server, a group of servers, and/or other like devices. In some non-limiting embodiments or aspects, transaction database 106 may include a plurality of transaction records.

[0087] In some non-limiting embodiments or aspects, acquirer system 108 may include one or more computing devices capable of receiving information from and/or communicating information to transaction processing system 104. For example, acquirer system 108 may include a server, a group of servers, and/or other like devices.

[0088] In some non-limiting embodiments or aspects, merchant system(s) 1 10 may include one or more computing devices capable of receiving information from and/or communicating information to acquirer system 108 and/or a payment gateway (not shown in FIG. 1 ). For example, merchant system(s) 1 10 may include a server, a group of servers, a client device, a group of client devices, and/or other like devices. In some examples, merchant system(s) 1 10 may include one or more client devices. For example, merchant system(s) 1 10 may include a client device that allows a merchant to communicate information to transaction processing system 104. Merchant system(s) 1 10 may include one or more devices such as computing devices 1 16 and/or peripheral devices capable of being used by a merchant to conduct a transaction with a user. For example, merchant system(s) 1 10 may include a POS device and/or a POS system.

[0089] In some non-limiting embodiments or aspects, scoring engine 1 12 may be part of transaction processing system 104. Additionally or alternatively, scoring engine 1 12 may be a separate computing device in communication with the transaction processing system 104 and configured to process data and/or information received from transaction processing system 104 and output one or more scores. For example, transaction processing system 104 may receive data and/or information from issuer system 102, transaction database 106, and/or acquirer system 108 which is then processed by scoring engine 1 12. In some non-limiting embodiments or aspects, scoring engine 1 12 may output one or more acquirer risk scores and/or merchant risk scores associated with one or more acquirers and/or merchants. In some non-limiting embodiments or aspects, scoring engine 112 may output a final acquirer risk score based on one or more acquirer scores and/or merchant scores.

[0090] In some non-limiting embodiments or aspects, output 1 14 may be the output of transaction processing system 104 and/or scoring engine 1 12. The output 114 may be communicated and inputted to computing device 1 16. In some non-limiting embodiments or aspects, output 1 14 may be an acquirer risk score, a merchant risk score, and/or a final acquirer risk score produced by scoring engine 1 12.

[0091] In some non-limiting embodiments or aspects, computing device 1 16 may include one or more computing devices capable of receiving information from transaction processing system 104 and/or scoring engine 1 12. For example, computing device 1 16 may be a personal computer, a server computer, and/or the like that receives the output 1 14 and displays and/or stores the acquirer risk score, merchant risk score, and/or final acquirer risk score.

[0092] The number and arrangement of systems and/or devices shown in FIG. 1 are provided as an example. There may be additional systems and/or devices; fewer systems and/or devices; different systems and/or devices; and/or differently arranged systems and/or devices than those shown in FIG. 1. Furthermore, two or more systems or devices shown in FIG. 1 may be implemented within a single system or device, or a single system or device shown in FIG. 1 may be implemented as multiple, distributed systems or devices. Additionally or alternatively, a set of systems (e.g., one or more systems) or a set of devices (e.g., one or more devices) of system 100 may perform one or more functions described as being performed by another set of systems or another set of devices of system 100.

[0093] FIG. 2 is a diagram of a process 200 for monitoring acquirer credit settlement risk according to non-limiting embodiments or aspects. The number and arrangement of steps shown in FIG. 2 are provided as an example. There may be additional, fewer, and different steps, and the steps may be performed in alternative orders in some examples. In some non-limiting embodiments or aspects, process 200 may be performed by acquirer system 202 and include acquirer risk score assessment step 204, merchant risk score assessment step 206, label assessment step 208, regression/ensemble learning step 210, learned aggregation step 212, default aggregation step 214, and/or final risk score 216.

[0094] In some non-limiting embodiments or aspects, the process 200 may begin when acquirer system 202 outputs a plurality of transaction records. In some nonlimiting embodiments or aspects, the plurality of transaction records may be associated with acquirer system 202 and at least one merchant corresponding to acquirer system 202. In some non-limiting embodiments or aspects, acquirer system 202 may be the same as or similar to acquirer system 108 (shown in FIG. 1 ).

[0095] In some non-limiting embodiments or aspects, acquirer risk score assessment step 204 may include receiving the plurality of transaction records from acquirer system 202. Acquirer risk score assessment step 204 may output a first acquirer risk score, a second acquirer risk score, and/or a third acquirer risk score, which may be received at label assessment step 208. [0096] In some non-limiting embodiments or aspects, acquirer risk score assessment step 204 may include generating a first acquirer risk score based on the plurality of transaction records and a first risk algorithm. For example, acquirer risk score assessment step 204 may include performing a direct assessment of the plurality of transaction records and/or generating a first acquirer risk score. In some non-limiting embodiments or aspects, performing a direct assessment may include a document analysis and/or a concentration analysis. For example, acquirer risk score assessment step 204 may include receiving a plurality of transaction records from acquirer system 202 in the form of textual documents (e.g., financial news, financial reports, and/or the like). The plurality of transaction records may be analyzed at acquirer risk score assessment step 204 based on a name entity recognition algorithm configured to recognize at least one acquirer system associated with each of the plurality of transaction records. Additionally or alternatively, acquirer risk score assessment step 204 may include performing a concentration analysis by analyzing a concentration of the plurality of transaction records in the form of textual documents based on transaction payments for future services to determine a risk associated with future chargeback requests.

[0097] In some non-limiting embodiments or aspects, acquirer risk score assessment step 204 may include generating a second acquirer risk score based on the plurality of transaction records and a second risk algorithm. For example, acquirer risk score assessment step 204 may include performing a temporal analysis of the plurality of transaction records and/or generating the second acquirer risk score based on a temporal analysis of the plurality of transaction records. In some non-limiting embodiments or aspects, performing a temporal analysis may include determining a time period associated with each of the plurality of transaction records and performing a time-series analysis of the plurality or transaction records based on the predetermined time period to detect a risk associated with abnormal transactions. In some non-limiting embodiments or aspects, acquirer risk score assessment step 204 may include generating a graph of the plurality of transaction records over the predetermined period of time. In some non-limiting embodiments or aspects, acquirer risk score assessment step 204 may include analyzing the graph. For example, analyzing the at least one relational graph may include determining whether the graph indicates an abnormality by analyzing a pattern of the plurality of transaction records over the predetermined period of time. [0098] In some non-limiting embodiments or aspects, acquirer risk score assessment step 204 may include generating a third acquirer risk score based on the plurality of transaction records and a third risk algorithm. For example, acquirer risk score assessment step 204 may include performing a peer assessment and/or generating a third acquirer risk score. In some non-limiting embodiments or aspects, performing a peer assessment may include identifying similar peers (e.g., acquirer systems and/or merchants) to the subject (e.g., the acquirer system associated with at least one transaction record) and/or identifying whether the subject behaves differently from its peers (e.g., similar acquirer systems and/or merchants). In some non-limiting embodiments or aspects, acquirer risk score assessment step 204 may include the use of graph learning. For example, acquirer risk score assessment step 204 may include performing a graph analysis by generating at least one relational graph based on the plurality of transaction records including a plurality of nodes and/or a plurality of edges.

[0099] In some non-limiting embodiments or aspects, the plurality of nodes may include a plurality of acquirer system nodes and/or a plurality of merchant nodes. For example, the plurality of acquirer system nodes may include at least one node for the acquirer system 202 associated with each of the plurality of transaction records, and/or the plurality of merchant nodes may include at least one node for the merchant corresponding to the acquirer system 202 for each of the plurality of transaction records. In some non-limiting embodiments or aspects, the plurality of edges may connect the plurality of nodes. For example, the plurality of edges may include an edge connecting each respective acquirer system node of the plurality of nodes with each merchant node of the plurality of merchant nodes, where the merchant corresponding to the acquirer system 202 is a client of the acquirer system 202. In some non-limiting embodiments or aspects, acquirer risk score assessment step 204 may include generating the third acquirer risk score based on the at least one relational graph. For example, acquirer risk score assessment step 204 may include generating the third acquirer risk score based on the number of edges connected to the at least one node for the acquirer system 202 for each of the plurality of transaction records.

[0100] In some non-limiting embodiments or aspects, merchant risk score assessment step 206 may include receiving the plurality of transaction records from acquirer system 202 and/or receiving data output by regression/ensemble learning step 210. In some non-limiting embodiments or aspects, merchant risk score assessment step 206 may include outputting a first merchant risk score, a second merchant risk score, and/or a third merchant risk score, which may be received at label assessment step 208.

[0101] In some non-limiting embodiments or aspects, merchant risk score assessment step 206 may include generating a first merchant risk score based on the plurality of transaction records and the first risk algorithm. For example, merchant risk score assessment step 206 may include performing a direct assessment of the plurality of transaction records and/or generating a first merchant risk score. In some non-limiting embodiments or aspects, the direct assessment may include a document analysis. For example, merchant risk score assessment step 206 may include receiving a plurality of transaction records from acquirer system 202 in the form of textual documents. The plurality of transaction records may be analyzed at merchant risk score assessment step 206 based on a name entity recognition algorithm configured to recognize at least one acquirer system associated with each of the plurality of transaction records.

[0102] In some non-limiting embodiments or aspects, merchant risk score assessment step 206 may include generating a second merchant risk score based on the plurality of transaction records and the second risk algorithm. For example, merchant risk score assessment step 206 may include performing a temporal analysis of the plurality of transaction records and/or generating the second merchant risk score based on the temporal analysis. In some non-limiting embodiments or aspects, performing the temporal analysis may include determining a time period associated with each of the plurality of transaction records and/or performing a time-series analysis of the plurality or transaction records based on the time period to detect a risk associated with abnormal transactions. Merchant risk score assessment step 206 may include leveraging historical transaction data to conduct a time-series analysis to identify changes in transaction patterns and catch a potential risk. In some non-limiting embodiments or aspects, merchant risk score assessment step 206 may include generating a graph of the plurality of transaction records over a predetermined period of time. In some non-limiting embodiments or aspects, merchant risk score assessment step 206 may include analyzing the graph. For example, analyzing the graph may include determining whether the graph indicates an abnormality by analyzing a pattern of the plurality of transaction records over the predetermined period of time. [0103] In some non-limiting embodiments or aspects, merchant risk score assessment step 206 may include generating a third merchant risk score based on the plurality of transaction records and the third risk algorithm. For example, merchant risk score assessment step 206 may include performing a peer assessment and/or generating a third merchant risk score. In some non-limiting embodiments or aspects, the peer assessment may include identifying similar peers to the subject and/or identifying whether the subject behaves differently from its peers. In some non-limiting embodiments or aspects, merchant risk score assessment step 206 may include the use of graph learning. For example, merchant risk score assessment step 206 may include performing a graph analysis by generating at least one relational graph based on the plurality of transaction records including a plurality of nodes and/or a plurality of edges.

[0104] In some non-limiting embodiments or aspects, the plurality of nodes may include a plurality of acquirer system nodes and/or a plurality of merchant nodes. For example, the plurality of acquirer system nodes may include at least one node for the acquirer system 202 associated with each of the plurality of transaction records, and/or the plurality of merchant nodes may include at least one node for the merchant corresponding to the acquirer system 202 for each of the plurality of transaction records. In some non-limiting embodiments or aspects, the plurality of edges may connect the plurality of nodes. For example, the plurality of edges may include an edge connecting each respective acquirer system node of the plurality of nodes with each merchant node of the plurality of merchant nodes, where the merchant corresponding to the acquirer system 202 is a client of the acquirer system 202. In some non-limiting embodiments or aspects, merchant risk score assessment step 206 may include generating the third merchant risk score based on the at least one relational graph. For example, merchant risk score assessment step 206 may include generating the third merchant risk score based on the number of edges connected to the at least one node for the merchant corresponding to the acquirer system 202 for each of the plurality of transaction records.

[0105] In some non-limiting embodiments or aspects, label assessment step 208 may include receiving a first acquirer risk score, a second acquirer risk score, a third acquirer risk score, a first merchant risk score, a second merchant risk score, and/or a third merchant risk score as a result of acquirer risk score assessment step 204 and/or merchant risk score assessment step 206. In some non-limiting embodiments or aspects, label assessment step 208 may include determining whether a supervised learning model or an unsupervised learning model was used to obtain the scores outputted by acquirer risk score assessment step 204 and/or merchant risk score assessment step 206. For example, label assessment step 208 may include determining whether output data received from acquirer risk score assessment step 204 and/or merchant risk score assessment step 206 is the result of a supervised learning model (e.g., trained using labeled data) or an unsupervised learning model (e.g., trained using data without a label). If at label assessment step 208 it is determined that the data received from acquirer risk score assessment step 204 and/or merchant risk score assessment step 206 is labeled data (e.g., “YES”), then the data may be received at regression/ensemble learning step 210. If at label assessment step 208 it is determined that the data received from acquirer risk score assessment step 204 and/or merchant risk score assessment step 206 is not labeled data (e.g., “NO”), then the unlabeled data may be received at default aggregation step 214.

[0106] In some non-limiting embodiments or aspects, regression/ensemble learning step 210 may include the use of at least one regression and/or ensemble learning algorithm to predict continuous values of the data set received from label assessment step 208. In some non-limiting embodiments or aspects, regression/ensemble learning aggregation step 210 may output data which may be received by merchant risk score assessment step 206 and/or learned aggregation step 212.

[0107] In some non-limiting embodiments or aspects, and with continued reference to FIG. 2, learned aggregation step 212 may include the use of at least one learned aggregation algorithm to perform risk score aggregation of the data received from regression/ensemble learning aggregation step 210. Learned aggregation step 212 may output final risk score 216. For example, learned aggregation step 212 may use at least one learned aggregation algorithm to aggregate the data and generate and output final risk score 216.

[0108] In some non-limiting embodiments or aspects, default aggregation step 214 may include the use of at least one default aggregation algorithm to aggregate the data received from label assessment step 208. Default aggregation step 214 may generate and/or output final risk score 216. For example, default aggregation step 214 may use at least one default aggregation algorithm to aggregate the data and generate and output final risk score 216. [0109] In some non-limiting embodiments or aspects, final risk score 216 may be the same as, similar to, and/or part of output 1 14 (shown in FIG. 1 ). Final risk score 216 may be an aggregation of the first acquirer risk score, the second acquirer risk score, the third acquirer risk score, the first merchant risk score, the second merchant risk score, and/or the third merchant risk score.

[0110] FIG. 3 is a flow diagram of a process 300 for monitoring acquirer credit settlement risk according to non-limiting embodiments or aspects. The number and arrangement of steps shown in FIG. 3 are provided as an example. There may be additional, fewer, and different steps, and the steps may be performed in an alternative order in some examples. In some non-limiting embodiments or aspects, process 300 may be performed by acquirer system 302 and include direct assessment step 304, document analysis step 306, concentration analysis step 308, and/or first acquirer risk score 310.

[0111] In some non-limiting embodiments or aspects, process 300 may begin when acquirer system 302 outputs a plurality of transaction records which may be received by direct assessment step 304. In some non-limiting embodiments or aspects, the plurality of transaction records may be associated with acquirer system 302 and at least one merchant corresponding to acquirer system 302. In some non-limiting embodiments or aspects, acquirer system 302 may be the same as or similar to acquirer systems 108 and/or 202 (shown in FIGS. 1 -2).

[0112] In some non-limiting embodiments or aspects, document analysis step 306 may include receiving a plurality of transaction records from direct assessment step 304 in the form of textual documents. In some non-limiting embodiments or aspects, document analysis step 306 may include analyzing the plurality of transaction records based on a name entity recognition algorithm configured to recognize the at least one acquirer system associated with each of the plurality of transaction records. In some non-limiting embodiments or aspects, document analysis step 306 may include generating first acquirer risk score 310 based on the plurality of transaction records and the first risk algorithm.

[0113] In some non-limiting embodiments or aspects, concentration analysis step 308 may include receiving a plurality of transaction records from direct assessment step 304 in the form of textual documents. In some non-limiting embodiments or aspects, concentration analysis step 308 may include analyzing a concentration of the plurality of transaction records based on transaction payments for future services to determine a risk associated with future chargeback requests. In some non-limiting embodiments or aspects, concentration analysis step 308 may include generating first acquirer risk score 310 based on the plurality of transaction records and the first risk algorithm.

[0114] In some non-limiting embodiments or aspects, first acquirer risk score 310 may be the same as, similar to, and/or part of output 1 14 (shown in FIG. 1 ).

[0115] FIG. 4 is a flow diagram of a process 400 for monitoring acquirer credit settlement risk according to non-limiting embodiments or aspects. The number and arrangement of steps shown in FIG. 4 are provided an as example. There may be additional, fewer, and different steps, and the steps may be performed in alternative orders in some examples. In some non-limiting embodiments or aspects, process 400 may be performed by acquirer system 402 and include temporal assessment step 404, time series-analysis step 406, and/or second acquirer risk score 408.

[0116] In some non-limiting embodiments or aspects, process 400 may begin when acquirer system 402 outputs a plurality of transaction records which may be received by temporal assessment step 404. The plurality of transaction records may be associated with acquirer system 402 and at least one merchant corresponding to acquirer system 402. In some non-limiting embodiments or aspects, acquirer system 402 may be the same as or similar to acquirer systems 108, 202, and/or 302.

[0117] In some non-limiting embodiments or aspects, temporal assessment step 404 may include performing a temporal analysis of the plurality of transaction records.

[0118] In some non-limiting embodiments or aspects, time-series analysis step 406 may include receiving the plurality of transaction records output by temporal assessment step 404. In some non-limiting embodiments or aspects, time-series analysis step 406 may include performing a time series analysis of the plurality of transaction records. For example, time-series analysis step 406 may include determining a time period associated with each of the plurality of transaction records and performing a time-series analysis of the plurality of transaction records based on the time period to detect a risk associated with abnormal transactions. In some nonlimiting embodiments or aspects, time-series analysis step 406 may include generating a graph of the plurality of transaction records over the predetermined period of time. In some non-limiting embodiments or aspects, time-series analysis step 406 may include analyzing the graph. For example, the graph may be analyzed to determine whether a pattern of the plurality of transaction records over the predetermined period of time indicates an abnormality. If an abnormality exists, timeseries analysis step 406 may include detecting a risk associated with the abnormality. In some non-limiting embodiments or aspects, time-series analysis step 406 may include generating second acquirer risk score 408 based on the plurality of transaction records and the second risk algorithm.

[0119] In some non-limiting embodiments or aspects, second acquirer risk score 408 may be the same as, similar to, and/or part of output 1 14 (shown in FIG. 1 ).

[0120] FIG. 5 is a flow diagram of a process 500 for monitoring acquirer credit settlement risk according to non-limiting embodiments or aspects. The number and arrangement of steps shown in FIG. 5 are provided as an example. There may be additional, fewer, and different steps, and the steps may be performed in alternative orders in some examples. In some non-limiting embodiments or aspects, process 500 may be performed by acquirer system 502 and include peer assessment step 504, graph analysis step 506, determine most similar peers step 508, and/or third acquirer risk score 510.

[0121] In some non-limiting embodiments or aspects, acquirer system 502 outputs a plurality of transaction records which may be received by peer assessment step 504. The plurality of transaction records may be associated with acquirer system 502 and at least one merchant corresponding to acquirer system 502. In some non-limiting embodiments or aspects, acquirer system 502 may be the same as or similar to acquirer systems 108, 202, 302, and/or 402 (shown in FIGS. 1 -4).

[0122] In some non-limiting embodiments or aspects, peer assessment step 504 may include performing a peer assessment of the plurality of transaction records.

[0123] In some non-limiting embodiments or aspects, graph analysis step 506 may include receiving the plurality of transaction records output by peer assessment step 504. In some non-limiting embodiments or aspects, graph analysis step 506 may include generating at least one relational graph based on the plurality of transaction records including a plurality of nodes and/or a plurality of edges. In some non-limiting embodiments or aspects, the plurality of nodes may include a plurality of acquirer system nodes and/or a plurality of merchant nodes. For example, the plurality of acquirer system nodes may include at least one node for the acquirer system 502 associated with each of the plurality of transaction records, and/or the plurality of merchant nodes may include at least one node for the merchant corresponding to the acquirer system 502 for each of the plurality of transaction records. In some non- limiting embodiments or aspects, the plurality of edges may connect the plurality of nodes. For example, the plurality of edges may include an edge connecting each respective acquirer system node of the plurality of nodes with each merchant node of the plurality of merchant nodes, where the merchant corresponding to the acquirer system 502 is a client of the acquirer system 502.

[0124] In some non-limiting embodiments or aspects, determine most similar peers step 508 may include identifying similar peers to the subject and/or identifying whether the subject behaves differently from its peers. In some non-limiting embodiments or aspects, determine most similar peers step 508 may include generating third acquirer risk score 510 based on the plurality of transaction records and the third risk algorithm. [0125] In some non-limiting embodiments or aspects, third acquirer risk score 510 may be the same as, similar to, and/or part of output 1 14 (Shown in FIG. 1 ).

[0126] FIG. 6 is a flow diagram of a process 600 for monitoring acquirer credit settlement risk according to non-limiting embodiments or aspects. The number and arrangement of steps shown in FIG. 6 are provided as an example. There may be additional, fewer, and different steps, and the steps may be performed in alternative orders in some examples. In some non-limiting embodiments or aspects, process 600 may include merchant 602, direct assessment step 604, document analysis step 606, and/or first merchant risk score 608. In some non-limiting embodiments or aspects, steps 604 and/or 606 may be the same as or similar to steps 304 and/or 306.

[0127] In some non-limiting embodiments or aspects, merchant 602 may output a plurality of transaction records which may be received by direct assessment step 604. In some non-limiting embodiments or aspects, the plurality of transaction records may be associated with an acquirer system and at least one merchant 602 corresponding the acquirer system.

[0128] In some non-limiting embodiments or aspects, document analysis step 606 may include receiving a plurality of transaction records in the form of textual documents from direct assessment step 604. In some non-limiting embodiments or aspects, document analysis step 606 may include analyzing the plurality of transaction records based on a name entity recognition algorithm configured to recognize at least one acquirer system associated with each of the plurality of transaction records. In some non-limiting embodiments or aspects, document analysis step 606 may include generating first merchant risk score 608 based on the plurality of transaction records and the first risk algorithm. [0129] In some non-limiting embodiments or aspects, first merchant risk score 608 may be the same as, similar to, and/or part of output 1 14 (shown in FIG. 1 ).

[0130] FIG. 7 is a flow diagram of a process 700 for monitoring acquirer credit settlement risk according to non-limiting embodiments or aspects. The number and arrangement of steps shown in FIG. 7 are provided as an example. There may be additional, fewer, and different steps, and the steps may be performed in alternative orders in some examples. In some non-limiting embodiments or aspects, process 700 may include merchant 702, temporal assessment step 704, time-series analysis step 706, and/or second merchant risk score 708. In some non-limiting embodiments or aspects, steps 704, 706, and/or 708 may be the same as or similar to steps 404, 406, and/or 408.

[0131] In some non-limiting embodiments or aspects, merchant 702 may be the same as, similar to, and/or part of merchant 602. In some non-limiting embodiments or aspects, merchant 702 may output a plurality of transaction records. The plurality of transaction records may be associated with an acquirer system and at least one merchant 702 corresponding to the acquirer system.

[0132] In some non-limiting embodiments or aspects, temporal assessment step 704 may include receiving a plurality of transaction records from merchant 702. In some non-limiting embodiments or aspects, temporal assessment step 704 may include performing a temporal analysis of the plurality of transaction records.

[0133] In some non-limiting embodiments or aspects, time-series analysis step 706 may include receiving the plurality of transaction records output by temporal assessment step 704. In some non-limiting embodiments or aspects, time-series analysis step 706 may include performing a time-series analysis of the plurality of transaction records. For example, time-series analysis step 706 may include determining a time period associated with each of the plurality of transaction records and performing a time-series analysis of the plurality of transaction records based on the time period to detect a risk associated with abnormal transactions. In some nonlimiting embodiments or aspects, time-series analysis step 706 may include generating a graph of the plurality of transaction records over the predetermined period of time. In some non-limiting embodiments or aspects, time-series analysis step 706 may include analyzing the graph. For example, the graph may be analyzed to determine whether a pattern of the plurality of transaction records over the predetermined period of time indicates an abnormality. If an abnormality exists, time- series analysis step 706 may include detecting a risk associated with the abnormality. In some non-limiting embodiments or aspects, time-series analysis step 706 may include generating second merchant risk score 708 based on the plurality of transaction records and the second risk algorithm.

[0134] In some non-limiting embodiments or aspects, second merchant risk score 708 may be the same as, similar to, and/or part of output 1 14 (shown in FIG. 1 ).

[0135] FIG. 8 is a flow diagram of a process 800 for monitoring acquirer credit settlement risk according to non-limiting embodiments or aspects. The number and arrangement of steps shown in FIG. 8 are provided as an example. There may be additional, fewer, and different steps, and the steps may be performed in alternative orders in some examples. In some non-limiting embodiments or aspects, process 800 may include merchant 802, peer assessment step 804, graph analysis step 806, determine most similar peers step 808, and/or third merchant risk score 810. In some non-limiting embodiments or aspects, steps 804, 806, and/or 808 may be the same as or similar to steps 504, 506, and/or 508.

[0136] In some non-limiting embodiments or aspects, merchant 802 may be the same as, similar to, and/or part of merchant 602 and/or merchant 702. In some nonlimiting embodiments or aspects, merchant 802 may output a plurality of transaction records. The plurality of transaction records may be associated with an acquirer system and at least one merchant 802 corresponding to the acquirer system.

[0137] In some non-limiting embodiments or aspects, peer assessment step 804 may include receiving a plurality of transaction records from merchant 802. In some non-limiting embodiments or aspects, peer assessment step 804 may include performing a peer assessment of the plurality of transaction records.

[0138] In some non-limiting embodiments or aspects, graph analysis step 806 may include receiving the plurality of transaction records output by peer assessment step 804. In some non-limiting embodiments or aspects, graph analysis step 806 may include generating at least one relational graph based on the plurality of transaction records including a plurality of nodes and/or a plurality of edges. In some non-limiting embodiments or aspects, the plurality of nodes may include a plurality of acquirer system nodes and/or a plurality of merchant nodes. For example, the plurality of acquirer system nodes may include at least one node for the acquirer system associated with each of the plurality of transaction records and/or the plurality of merchant nodes may include at least one node for the merchant 802 corresponding to the acquirer system for each of the plurality of transaction records. In some non-limiting embodiments or aspects, the plurality of edges may connect the plurality of nodes. For example, the plurality of edges may include an edge connecting each respective acquirer system node of the plurality of nodes with each merchant node of the plurality of merchant nodes, where the merchant 802 corresponding to the acquirer system is a client of the acquirer system.

[0139] In some non-limiting embodiments or aspects, determine most similar peers step 808 may include identifying similar peers to the subject and/or identifying whether the subject behaves differently from its peers. In some non-limiting embodiments or aspects, determine most similar peers step 808 may include generating third merchant risk score 810 based on the plurality of transaction records and the third risk algorithm. [0140] In some non-limiting embodiments or aspects, third merchant risk score 810 may be the same as, similar to, and/or part of output 1 14 (show in FIG. 1 ).

[0141] FIG. 9 is a schematic diagram of a system 900 for monitoring acquirer credit settlement risk according to non-limiting embodiments or aspects. The number and arrangement of modules shown in FIG. 9 are provided as an example. There may be additional, fewer, and different modules in some non-limiting embodiments or aspects. A module may be, for example, hardware and/or software configured to perform one or more actions (e.g., such as one or more software routines, software applications, computing devices configured with software, and/or the like). Modules may be, for example, software routines performed by one or more software applications executing on one or more computing devices. System 900 includes transaction module 902 and/or graph module 904.

[0142] In some non-limiting embodiments or aspects, transaction module 902 may include aggregating transactions module 906 (including merchant transaction sequences and acquirer transaction sequences), LSTM/transformer or auto encoder module 908, and/or embedding module 910. Aggregating transactions module 906 may aggregate a plurality of merchant transaction records and/or acquirer transaction records and output merchant and/or acquirer data (e.g., merchant transaction sequences and/or acquirer transactions sequences) which may be received at LSTM/ transformer or auto encoder module 908. LSTM/transformer or auto encoder module 908 may determine whether the data is labeled (e.g., a supervised module was used) or unlabeled (e.g., an unsupervised module was used). If the data is labeled (e.g., “Y”), then learned aggregation methods specific to the type of data will be performed at module 908. If the data is unlabeled (e.g., “N”), then default aggregation will be performed at module 908. In some non-limiting embodiments or aspects, LSTM/transformer or auto encoder module 908 may output merchant and/or acquirer data which may be received by embedding module 910. In some non-limiting embodiments or aspects, embedding module 910 may embed the merchant and/or acquirer data.

[0143] In some non-limiting embodiments or aspects, graph module 904 may include node output module 912, graphing module 914, graph learning module 916, and/or determine peers module 918. Node output module 912 may use embedded merchant and/or acquirer data to output a plurality of merchant and/or acquirer nodes. The plurality of acquirer system nodes may include at least one node for the acquirer system associated with each of the plurality of transaction records and/or the plurality of merchant nodes may include at least one node for the merchant corresponding to the acquirer system for each of the plurality of transaction records. Graphing module 914 may receive the plurality of merchant and/or acquirer nodes and generate a bipartite graph with a first vertex representing at least one acquirer and a second vertex representing at least one merchant. In some non-limiting embodiments or aspects, graph learning module 916 may perform a graph analysis of the bipartite graph. At determine peers module 918, the results of the graph analysis may be used to determine the most similar merchant and/or acquirer peers.

[0144] FIG. 10 shows a relational graph 1000 according to non-limiting embodiments or aspects associated with process 200 shown in FIG. 2. As shown in FIG. 10, relational graph 1000 may include data represented as a plurality of acquirer system nodes 1002, a plurality of merchant nodes 1004, and a plurality of edges 1006.

[0145] In some non-limiting embodiments or aspects, the plurality of nodes 1002 and 1004 may include a plurality of acquirer system nodes 1002 (e.g., darker nodes) and/or a plurality of merchant nodes 1004 (e.g., lighter nodes). For example, the plurality of acquirer system nodes 1002 may include at least one node for the acquirer system associated with each of a plurality of transaction records, and/or the plurality of merchant nodes 1004 may include at least one node for the merchant corresponding to the acquirer system for each of the plurality of transaction records.

[0146] In some non-limiting embodiments or aspects, the plurality of edges 1006 may connect the plurality of nodes 1002 and 1004. For example, the plurality of edges 1006 may include an edge connecting each respective acquirer system node 1002 with each merchant node 1004 of the plurality of merchant nodes, where the merchant corresponding to the acquirer system is a client of the acquirer system.

[0147] The number and arrangement of nodes and edges shown in FIG. 10 are provided as an example. In some non-limiting embodiments or aspects, relational graph 1000 may include additional nodes and/or edges, fewer nodes and/or edges, different nodes and/or edges, or differently arranged nodes and/or edges than those shown in FIG. 10.

[0148] FIG. 1 1 is a diagram of example components of a device 1 100. Device 1 100 may correspond to one or more devices of issuer system 102, one or more devices of transaction processing system 104, transaction data 106, one or more devices of acquirer system 108, and/or one or more devices of merchant system(s) 1 10. In some non-limiting embodiments or aspects, issuer system 102, transaction processing system 104, transaction data 106, acquirer system 108, and/or merchant system(s) 1 10 may include at least one device 1 100 and/or at least one component of device 1 100. As shown in FIG. 1 1 , device 1 100 may include bus 1 102, processor 1 104, memory 1 106, storage component 1 108, input component 1 1 10, output component 1 1 12, and communication interface 1 1 14.

[0149] Bus 1 102 may include a component that permits communication among the components of device 1 100. In some non-limiting embodiments or aspects, processor 1 104 may be implemented in hardware, software, firmware, and/or any combination thereof. For example, processor 1 104 may include a processor (e.g., a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), and/or the like), a microprocessor, a digital signal processor (DSP), and/or any processing component (e.g., a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), and/or the like), and/or the like, which can be programmed to perform a function. Memory 1 106 may include random access memory (RAM), read-only memory (ROM), and/or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, optical memory, and/or the like) that stores information and/or instructions for use by processor 1 104.

[0150] Storage component 1108 may store information and/or software related to the operation and use of device 1 100. For example, storage component 1 108 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, a solid state disk, and/or the like), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cartridge, a magnetic tape, and/or another type of computer-readable medium, along with a corresponding drive.

[0151 ] Input component 11 10 may include a component that permits device 1 100 to receive information, such as via user input (e.g., a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, a microphone, a camera, and/or the like). Additionally or alternatively, input component 1 1 10 may include a sensor for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, an actuator, and/or the like). Output component 1 1 12 may include a component that provides output information from device 1 100 (e.g., a display, a speaker, one or more light-emitting diodes (LEDs), and/or the like).

[0152] Communication interface 1 114 may include a transceiver-like component (e.g., a transceiver, a receiver and transmitter that are separate, and/or the like) that enables device 1 100 to communicate with other devices, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections. Communication interface 1 1 14 may permit device 1 100 to receive information from another device and/or provide information to another device. For example, communication interface 11 14 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi® interface, a Bluetooth® interface, a Zigbee® interface, a cellular network interface, and/or the like.

[0153] Device 1 100 may perform one or more processes described herein. Device 1 100 may perform these processes based on processor 1 104 executing software instructions stored by a computer-readable medium, such as memory 1 106 and/or storage component 1 108. A computer-readable medium (e.g., a non-transitory computer-readable medium) is defined herein as a non-transitory memory device. A non-transitory memory device includes memory space located inside of a single physical storage device or memory space spread across multiple physical storage devices.

[0154] Software instructions may be read into memory 1 106 and/or storage component 1 108 from another computer-readable medium or from another device via communication interface 1 1 14. When executed, software instructions stored in memory 1 106 and/or storage component 1 108 may cause processor 1 104 to perform one or more processes described herein. Additionally or alternatively, hardwired circuitry may be used in place of or in combination with software instructions to perform one or more processes described herein. Thus, embodiments described herein are not limited to any specific combination of hardware circuitry and software.

[0155] The number and arrangement of components shown in FIG. 1 1 are provided as an example. In some non-limiting embodiments or aspects, device 1 100 may include additional components, fewer components, different components, or differently arranged components than those shown in FIG. 1 1 . Additionally or alternatively, a set of components (e.g., one or more components) of device 1 100 may perform one or more functions described as being performed by another set of components of device 1 100.

[0156] Although the disclosed subject matter has been described in detail for the purpose of illustration based on what is currently considered to be the most practical and preferred embodiments or aspects, it is to be understood that such detail is solely for that purpose and that the disclosed subject matter is not limited to the disclosed embodiments or aspects, but, on the contrary, is intended to cover modifications and equivalent arrangements that are within the spirit and scope of the appended claims. For example, it is to be understood that the presently disclosed subject matter contemplates that, to the extent possible, one or more features of any embodiment or aspect can be combined with one or more features of any other embodiment or aspect.