This application claims the benefit of, and priority to, U.S. Non- Provisional Application No. 15/179,114 filed on June 10, 2016. The entire disclosure of the above application is incorporated herein by reference. FIELD

The present disclosure generally relates to systems and methods for enabling performance review of certified authentication services, and in particular, to measuring performance metrics of the authentication services, when implemented for use with payment networks, relative to defined thresholds.

BACKGROUND

This section provides background information related to the present disclosure which is not necessarily prior art.

Payment accounts are used by consumers to perform numerous different transactions including, for example, purchasing products from merchants, etc. When the payment accounts are provided to fund the transactions, the consumers are authenticated, often by signatures or PINs, to the merchants (or to point of sale (POS) terminals of the merchants). Other forms of authentication are also known, including, for example, authentication using biometrics, challenge questions, etc. Despite the different forms of authentication, in certain instances, unauthorized persons or entities still attempt to use the payment accounts to cause unauthorized transactions. As such, merchants to which the transactions are directed and issuers of the payment accounts are known to rely on enhanced authentication and authorization techniques to limit the number of such unauthorized transactions. The enhanced techniques, for example, generally involve additional services associated with the merchants, the issuers, and/or payment networks involved in processing/facilitating the transactions. DRAWINGS

The drawings described herein are for illustrative purposes only of selected embodiments and not all possible implementations, and are not intended to limit the scope of the present disclosure.

FIG. 1 illustrates an exemplary system for enabling performance review of certified authentication services, and including one or more aspects of the present disclosure;

FIG. 2 is a block diagram of an exemplary computing device, suitable for use in the system of FIG. 1; and

FIG. 3 is a flowchart of an exemplary method, which can be implemented via the system of FIG. 1, for measuring performance metrics of the certified authentication services relative to defined thresholds when implemented for use with a payment network.

Corresponding reference numerals indicate corresponding parts throughout the several views of the drawings.

DETAILED DESCRIPTION

Exemplary embodiments will now be described more fully with reference to the accompanying drawings. The description and specific examples included herein are intended for purposes of illustration only and are not intended to limit the scope of the present disclosure.

Purchase transactions are known to include, or require, one or more forms of authentication when funded through payment accounts. However, as services, including authentication services (provided by payment networks or other service providers), are appended to processes of authorizing the transactions, delays associated with the additional services may negatively impact consumer purchasing experiences. The delays are often attributed, by consumers and merchants, for example, to the payment networks regardless of their actual source. As such, payment networks often employ certification procedures to certify the additional services, including authentication services, prior to permitting their implementation to help inhibit such delays.

Uniquely, the systems and methods herein permit performance review of previously certified authentication services, when implemented, and further permit advisements and remediation of issues therewith. In particular, performance metrics of such services are measured, at one or more defined intervals, and then compared to one or more defined thresholds. The service providers offering the services are then advised of the measured metrics (often, whether the thresholds are satisfied or not), and when the thresholds are not satisfied, advised of remedial actions to alter the performance of the services, and in some instances, deadlines and consequences for failure to implement the remedial actions. In this manner, even after certification, authentication services are reviewed to reduce impact of service provider caused delays, security issues, and/or acceptance issues associated with misuse or errant implementation of the authentication services.

FIG. I illustrates an exemplary system 100 in which one or more aspects of the present disclosure may be implemented. Although parts of the system 100 are presented in one arrangement, it should be appreciated that other exemplary embodiments may include the same or different parts arranged otherwise, depending on, for example, the manner in which consumers are authenticated, the manner in which transactions are processed, etc.

As shown in FIG. 1 , the illustrated system 100 generally includes a merchantl02, an acquirer 104, a payment network 106, and an issuer 108, each coupled to one or more networks. Regardless of the arrangement of the one or more networks, or even the number of such networks in FIG. 1, network connections are generally indicated by arrowed lines between the various particular parts of the system 100. In addition, it should be appreciated that a lack of arrowed lines between different parts of the system 100 does not imply that those parts are not connected or capable of connecting via a network (the arrows may simply be omitted in FIG. 1 for ease of illustration).

The networks of the system 100 may include, without limitation, wired and/or wireless networks, local area networks (LANs), wide area networks (WANs) (e.g., the Internet, etc.), mobile networks, and/or other suitable public and/or private networks capable of supporting communication among two or more of the illustrated parts of the system 100, or any combination thereof. In one example, one of the networks includes multiple networks, where different ones of the multiple networks are accessible to different ones of the illustrated parts in FIG. 1. In particular in this example, the acquirer 104, the payment network 106, and the issuer 108 may be connected via a private network for processing purchase transactions, and the merchant 102 may be connected with the acquirer 104 (or a merchant plug-in (MPI) 110), for example, through a public network, such as the Internet.

The merchant 102 of the system 100 provides products (e.g., goods and services, etc.), at physical store-front locations (e.g., at brick-and-mortar stores, etc.) and/or through virtual store-front locations (e.g., through network-based

applications/interfaces, etc.). The products are available for purchase by a consumer 112 in desired transactions. The present disclosure is described with reference to transactions in which the consumer 112 purchases products from the merchant 102 using a payment account issued to the consumer 112 by the issuer 108. However, it should be appreciated that the present disclosure encompasses a variety of other transaction scenarios, involving payments via channels other than payment accounts. In addition, the consumer 112 is associated with a communication device 114, which may be used (among other things) to facilitate network transactions (e.g., via the Internet, etc.) and/or card-not-present transactions (via a payment application containing the payment account, etc.) to purchase the products from the merchant 102 using the payment account.

In the illustrated embodiment, the consumer's payment account is associated with at least one enhanced authentication service, which requires the consumer 112 to enter codes or other identifiers known to the consumer 112 prior to conventional authorization of a transaction involving the payment account. The enhanced authentication service may include or involve, for example, one or more 3 Domain Secure (3DS) protocols such as SecureCode® by MasterCard, Verified® by VISA, Safekey® by American Express, etc.

With continued reference to FIG. 1, the system 100 includes additional parts, which participate in the enhanced authentication service associated with the consumer's payment account for certain transactions (e.g., for card-not-present transactions, etc.). In particular, the system 100 includes multiple service providers (broadly, vendors) such as the MPI 110 and an access control server (ACS) 116. As shown, each is coupled to the payment network 106, via one or more network connections (indicated by the arrowed lines). The MPI 110 and the ACS 116 may comprise any suitable computing devices and/or any protocols (e.g., including, but not limited to, 3DS protocols, etc.), for example, that take part in authenticating the consumer 112 prior to permitting/authorizing purchase transactions by the consumer 112 at the merchant 102 (and other consumers at the merchant 102 and/or at other merchants).

The MPI 110 of the system 100 is a service provider separate from the merchant 102 (in this embodiment), yet coupled thereto via one or more network connections to provide authentication messaging to/from the merchant 102, as described herein. In addition, the MPI 110 may provide services to other merchants (not shown) in the system 100. The ACS 116 is a service provider coupled to the issuer 108 via one or more network connections (and, potentially, to other issuers (not shown) in the system 100), whereby the ACS 116 provides authentication messaging on behalf of the issuer 108, as described herein. Prior to implementation of the messaging (broadly, services) by the MPI 110 and/or the ACS 1 16, however, the payment network 106 reviews, evaluates, tests and/or certifies the messaging services for use with the payment network 106. In the absence of the certification, the messaging services are not permitted, by the payment network 106, to participate in the enhanced authentication service.

While one MPI 110 and one ACS 116 are illustrated in the system 100 in FIG. 1, for ease of illustration, it should be appreciated that any number of MPIs and ACSs may be included in the system 100 or in other system embodiments. In addition, while the MPI 110 is illustrated as separate from the merchant 102 (and the acquirer 104), it may be incorporated with the merchant 102 and/or the acquirer 104 in other embodiments. Similarly, while the ACS 116 is illustrated as separate from the issuer 108, it may be incorporated therewith in other embodiments. Further, in at least one embodiment, the MPI 110 and/or the ACS 116, or certain aspects thereof, may be integrated with the payment network 106, or parts thereof.

An example transaction by the consumer 112 at the merchant 102 is described next, involving purchase of a product by the consumer 112 from a virtual store-front location of the merchant 102 using the consumer's payment account and the communication device 114. However, it should be appreciated that the present disclosure encompasses a variety of other transaction scenarios, involving other than payment accounts and/or involving other than communication devices.

When the consumer 112 presents credentials for the payment account to the merchant 102 for use in the purchase of the product (e.g., via the payment application at the consumer's communication device 114, etc.), the merchant 102 identifies the payment account. Because the transaction is initiated at the virtual store-front of the merchant 102, in this example, the transaction is directed to the MPI 110.

Upon receipt (or notification) of the transaction, by the merchant 102, the MPI 110 is configured to transmit an authentication message (as part of a request, for example) to the payment network 106 for the transaction, and the payment network 106 is configured to determine if the issuer 108 associated with the payment account is a participant in the enhanced authentication service described herein. In this example, the issuer 108 is a participant. As such, the payment network 106 is configured to search for the ACS 1 16 (e.g., an ACS address, etc.) associated with the issuer 108 and to transmit the authentication message to the ACS 116. The authentication message transmitted by the payment network 106 to the ACS 116 may include, for example, the exact message received from the MPI 110, a modified version of the message, or a new message incorporating the original authentication message in whole or in part from the MPI 110 and/or details associated therewith. The ACS 116 is configured to then verify whether or not the particular payment account associated with the consumer 112 is enrolled in the enhanced authentication service. If it is (as is the case in this example), the ACS 116 is configured to provide a response message including a verified indicator (or metric) back through the payment network 106 to the MPI 110. However, if the payment account is not enrolled, the ACS 116 is configured to provide a response message including a non- verified indicator back through the payment network 106 to the MPI 110. In either case, the response message transmitted by the payment network 106 to the MPI 110 may be the exact message received from the ACS 116, a modified version of the message, or a new message incorporating the original response message from the ACS in whole or in part and/or details associated therewith.

Upon receipt of the response message for the consumer's transaction, with the verified indicator included therein, the MPI 110 is configured to send a consumer authentication request to the virtual store-front of the merchant 102. The virtual store-front is configured to then communicate with the ACS 1 16 to perform authentication of the consumer 112. In particular, an interface is displayed from the ACS 116, as part of, or in a separate interface to, the virtual store-front, at communication device 114, for example, which prompts the consumer 112 to enter a code or other identifier (e.g., a biometric, etc.) particular to the consumer 112. In response to the code (or other identifier), the ACS 1 16 is configured to confirm the code and to generate an accountholder authentication value (AAV), which is transmitted to the MPI 110. The interface from the ACS 116 is then closed. In turn, the MPI 110 is configured to provide the AAV to the merchant 102, and in particular, to the merchant's virtual store-front. If the code (or other identifier) is not confirmed, however, the consumer 112 may be given an additional opportunity (or multiple additional opportunities) to submit the correct code (or other identifier). When the additional opportunity expires, and at discretion of the ACS 116, the merchant 102 is then prompted to decide whether to abort the transaction or submit it for authorization anyway (with certain fraud responsibility if the transaction is later determined to be fraudulent). It should be appreciated that the enhanced authentication service, described above in authenticating the consumer 112, may be different in other embodiments, but is preferably performed in addition to a conventional payment account authorization process between the consumer 112, the merchant 102, the acquirer 104, and the issuer 108.

Then in this example, based on the authentication of the consumer 112 as described above, the merchant 102 is configured to generate an authorization request in a conventional manner, to determine if the consumer's payment account is in good standing and if there is/are sufficient credit/funds to authorize the transaction. The authorization request includes, among other things, a payment account number, an amount of the transaction, and the AAV received from the enhanced authentication service. The authorization request is sent form the merchant 102 to the acquirer 104. In turn, the acquirer 104 is configured to communicate the authorization request to the issuer 108, via the payment network 106. The issuer 108 is configured to then validate the AAV, and other aspects of the authorization request to determine whether to authorize the transaction. The issuer 108 is configured to send an authorization response back through the payment network 106 to the acquirer 104, which is then provided back to the merchant 102. If the transaction is authorized, the credit line or funds associated with the payment account of the consumer 112, depending on the type of account, is decreased by the amount of the purchase, and the charge is posted to the consumer's payment account. The transaction is later cleared and settled by and between the merchant 102 and the acquirer 104 and by and between the acquirer 104 and the issuer 108 (in accordance with a settlement arrangement, etc.).

Alternatively, if the transaction is declined, the merchant 102 may terminate the transaction or request alternative forms of payment. While in the above example, the messages relating to authentication of the consumer 112 are described with reference to and are directed to and from the MPI 110 and/or the ACS 116, it should be appreciated that other messages related to a 3DS protocol, for example, or other security protocol, may be passed among the parts of the system 100, and be subjected to the methods herein.

In various exemplary embodiments, consumers (e.g., consumer 112, etc.) involved in the different transactions herein are prompted to agree to legal terms associated with their payment accounts, for example, during enrollment in their accounts, etc. In so doing, the consumers may voluntarily agree, for example, to allow merchants, issuers, payment networks, etc., to use data collected during enrollment and/or collected in connection with processing the transactions herein, subsequently for one or more of the different purposes described herein.

FIG. 2 illustrates an exemplary computing device 200 that can be used in the system 100. The computing device 200 may include, for example, one or more servers, workstations, personal computers, laptops, tablets, smartphones, POS terminals, other suitable computing devices, etc. In addition, the computing device 200 may include a single computing device, or it may include multiple computing devices located in close proximity, or multiple computing devices distributed over a geographic region, so long as the computing devices are specifically configured to function as described herein. In the system 100, each of the merchant 102, the acquirer 104, the payment network 106, the issuer 108, the MPI 1 10, and the ACS 1 16 are illustrated as including, or being implemented in, computing device 200. Also in the system 100, the communication device 114 associated with the consumer 112 is consistent with computing device 200. However, the system 100 should not be considered to be limited to the computing device 200, as described below, as different computing devices and/or arrangements of computing devices may be used. In addition, different components and/or arrangements of components may be used in other computing devices.

Referring to FIG. 2, the exemplary computing device 200 generally includes a processor 202 and a memory 204 coupled to (and in communication with) the processor 202. The processor 202 may include one or more processing units (e.g., in a multi-core configuration, etc.) including, without limitation, a central processing unit (CPU), a microcontroller, a reduced instruction set computer (RISC) processor, an application specific integrated circuit (ASIC), a programmable logic device (PLD), a gate array, and/or any other circuit or processor capable of the functions described herein. The above examples are exemplary only, and are not intended to limit in any way the definition and/or meaning of processor.

The memory 204, as described herein, is one or more devices that permit data, instructions, etc., to be stored therein and retrieved therefrom. The memory 204 may include one or more computer-readable storage media, such as, without limitation, dynamic random access memory (DRAM), static random access memory (SRAM), read only memory (ROM), erasable programmable read only memory (EPROM), solid state devices, flash drives, CD-ROMs, thumb drives, floppy disks, tapes, hard disks, and/or any other type of volatile or nonvolatile physical or tangible computer-readable media. The memory 204, and/or data structures included therein, may be configured to store, without limitation, transaction data,

authentication codes (or other identifiers), advisements, remedial actions, consequences, authentication outcomes, interfaces, and/or other types of data and/or information suitable for use as described herein. Furthermore, in various

embodiments, computer-executable instructions may be stored in the memory 204 for execution by the processor 202 to cause the processor 202 to perform one or more of the functions described herein, such that the memory 204 is a physical, tangible, and non-transitory computer readable storage media. It should be appreciated that the memory 204 may include a variety of different memories, each implemented in one or more of the functions or processes described herein.

The computing device 200 also includes a presentation unit 206 (or output device or display device) that is coupled to (and in communication with) the processor 202 (however, it should be appreciated that the computing device 200 could include output devices other than the presentation unit 206, etc.). The presentation unit 206 outputs information, either visually or audibly to a user of the computing device 200, for example, a consumer (e.g., the consumer 112, etc.), a payment network user (not shown), service provider user (not shown) or other user associated with other parts of the system 100, etc. It should be further appreciated that various interfaces (e.g., associated with authentication requests, etc.) may be displayed at computing device 200, and in particular at presentation unit 206, to display information, such as, for example, advisements, etc. The presentation unit 206 may include, without limitation, a liquid crystal display (LCD), a light-emitting diode (LED) display, an organic LED (OLED) display, an "electronic ink" display, etc. In some embodiments, presentation unit 206 includes multiple devices.

The computing device 200 further includes an input device 208 that receives inputs from the user of the computing device 200 (i.e., user inputs) such as, for example, authentication codes, etc. The input device 208 is coupled to (and is in communication with) the processor 202 and may include, for example, a keyboard, a pointing device, a mouse, a stylus, a touch sensitive panel (e.g., a touch pad or a touch screen, etc.), another computing device, and/or an audio input device. In various exemplary embodiments, a touch screen, such as that included in a tablet, a smartphone, or similar device, behaves as both a presentation unit 206 and an input device 208.

In addition, the illustrated computing device 200 also includes a network interface 210 coupled to (and in communication with) the processor 202 and the memory 204. The network interface 210 may include, without limitation, a wired network adapter, a wireless network adapter, a mobile network adapter, or other device capable of communicating to one or more different networks, including the network 110. Further, in some exemplary embodiments, the computing device 200 includes the processor 202 and one or more network interfaces incorporated into or with the processor 202.

Referring again to FIG. 1, the payment network 106 of the system 100 includes a review engine 118. While the review engine 118 is illustrated as a separate component included in the payment network 106 (i.e., separate from the computing device 200 of the payment network 106), it should be appreciated that it may be incorporated in the computing device 200, which operates as described herein. Still further, the review engine 118 may be disposed elsewhere in the system 100, for example, as a standalone device, integrated with other parts of the system 100 (e.g., in one or more of the MPI 110 and/or the ACS 116, etc.), etc.

In particular in the system 100, the review engine 118 is configured to enable performance review of certified authentication services associated with, for example, the MPI 110 and/or the ACS 116 (e.g. , the authentication services/messages provided in the above example transaction, etc.). In so doing, the engine 118 is configured to measure performance metrics provided by the services of the MPI 110 and/or the ACS 116. Example performance metrics are included, without limitation, in Table 1 below. In various implementations, the review engine 118 is also configured to enable performance review of authorization services herein.

After measuring the desired performance metrics, the review engine 118 is configured to compare the measured performance metrics to one or more defined thresholds (or sub-thresholds). The engine 1 18 is also configured to provide advisements to the service providers of the system 100 (e.g., the MPI 1 10 or ACS 116, etc.) when the thresholds are satisfied and/or not satisfied. When not satisfied, the engine 118 is configured to include remedial actions to be taken by the service providers and one or more deadlines to perform and/or accomplish the remedial actions. In addition, the engine 118 is configured to select the remedial actions, and select and provide consequences based, in part, on the severity of deficiencies related to the thresholds and/or the type of the performance metrics at issue (e.g., critical, major, minor, etc.), etc.

FIG. 3 illustrates an exemplary method 300 for use in measuring performance metrics of authentication services, when implemented for use with payment networks, relative to defined thresholds. The exemplary method 300 is described as implemented in the payment network 106 of the system 100 and, more particularly, in the MPI 110, the ACS 116, and the review engine 118. Further, for purposes of illustration, the exemplary method 300 is described herein with reference to other parts of the system 100 and the computing device 200. As should be understood, however, the methods herein should not be understood to be limited to the exemplary system 100 or the exemplary computing device 200, and the systems and the computing devices herein should not be understood to be limited to the exemplary method 300.

As described in the above example transaction between the merchant 102 and the consumer 112, the payment network 106 initially interacts, at 302, with the MPI 110 and/or the ACS 116, in providing enhanced authentication services for the transaction.

In connection therewith, the review engine 1 18 measures, at 304, one or multiple performance metrics of the messaging provided by the MPI 110 and/or the ACS 1 16 in association with the authentication services. As illustrated in Table 1 above, the performance metrics may include, without limitation, an availability of a vendor solution during a time of cardholder (e.g., consumer 112, etc.) verification, an availability of a vendor solution during a time of cardholder (e.g., consumer 112, etc.) authentication, an overall authentication approval rate of a vendor solution, a frequency of required cardholder (e.g., consumer 112, etc.) authentication for a risk based authentication, a frequency of activation during shopping for a cardholder (e.g., consumer 112, etc.) authentication, a frequency of activation during shopping for a cardholder (e.g., consumer 112, etc.) authentication, and a uniqueness of generated AAV by a vendor solution. The review engine 118 measures the one or multiple performance metrics at one or more defined intervals, such as, for example, hourly, every two hours, daily, monthly, etc. It should be appreciated that the defined intervals may be associated with the particular performance metric to be measured. For example the availability of a vendor solution during a time of cardholder (e.g., consumer 112, etc.) verification performance metric may be measured quarterly, while the overall authentication approval rate of a vendor solution performance metric may be measured monthly. Table 2 illustrates example intervals over which the review engine 118 may measure the example performance metrics from Table 1.

After measuring the performance metric, the review engine 118 next compares the measured performance metric to a defined threshold, at 306. The defined threshold is generally specific to the performance metric. For example, the defined threshold for the availability of a vendor solution during a time of cardholder (e.g., consumer 112, etc.) verification performance metric is 99%. Generally, the thresholds are defined by the payment network 106 to provide a specified level of performance from the services provided by the MPI 110 and/or the ASC 116 (and/or other service provider). The thresholds may be defined through a specification and/or through historical data related to the performance on multiple services interactions with the payment network 106, etc. Table 3 illustrates example thresholds against which the review engine 118 may compare the example performance metrics from Table 1, for example.

Then, at 308, the review engine 118 determines, based on the comparison, if the performance metrics satisfy the defined thresholds.

If the engine 118 determines that the performance metrics do not satisfy the defined thresholds (at 308), the review engine 1 18 identifies, at 310, remedial actions to be taken by the service provider (e.g., by the MPI 110 and/or the ACS 116 in the above example transaction, etc.). The remedial actions are generally predefined based on the performance metric at issue (e.g., improve the metric until it meets the predefined threshold, etc.). However, in some implementations, the review engine 118 may select/determine a particular remedial action based on the comparison (at 308) and/or the scope by which the performance metrics do not satisfy the defined thresholds, etc. In addition, the review engine 118 identifies, at 312, a consequence or multiple consequences for failure of the service provider to perform the remedial actions, and identifies, at 314, a deadline for the remedial action to be performed by the service provider. Such consequences may include, without limitation, warning letters (broadly, warnings), placing the service provider on probation, delisting the service provider from particular services, assessing a financial penalty, etc. As with the remedial actions, the consequences are generally predefined based on the performance metric at issue (but, again, this is not required in all embodiments). And, the deadlines are generally determined based on the performance metric and a type of the metric under review (and/or a finding indicated during the time of review, for example, how close the metric is to the defined threshold, etc.). For example, if the performance metric includes a uniqueness of a generated AAV by a vendor solution, and the performance metric does not satisfy the defined threshold (e.g., 100%, etc.), the service provider may be issued a warning and given thirty days to provide a resolution (e.g., modify the solution to satisfy the defined threshold, etc.). Table 4 includes exemplary deadlines for performing remedial actions for each of the example performance metrics in Table 1 (when the performance metrics are not satisfied).

Subsequently, in connection with determining that the performance metrics do not satisfy the defined thresholds (at 308), the review engine 118 advises the service provider regarding the failure of the performance metrics to satisfy the threshold. The advisement includes the measured performance metrics, the identified remedial action(s) to be taken, the identified consequence(s), and/or the identified deadline for performance of the remedial action(s). Initial advisements may be in the form of emails, short message service (SMS) messages, voice messages, etc. Then, if the defined thresholds are not satisfied within the remedial action timelines, formal letters (e.g., subsequent advisements, etc.) may be transmitted to the offending service providers (e.g., via mail, etc.) if the metrics at issue are of either a major or a critical type (see, Table 2).

As an example, if the defined threshold for the availability of a vendor solution during a time of cardholder (e.g., consumer 112, etc.) verification, of 99%, is not satisfied (at 308), the engine 118 may initially issue a warning letter to the offending service provider (e.g., the MPI 110, the ACS 116, etc.) and provide a deadline of 90 days to rectify the metric (i.e., to take remedial action to improve the availability to 99% or greater). Then, after the 90 day deadline, if the metric is not rectified, the engine 118 may issue a probation letter to the offending service provider placing the service provider on probation with the payment network 106. As another example, if the defined threshold for the overall authentication approval rate of a vendor solution, of 90%, is not satisfied (at 308), the engine 118 may electronically notify the offending service provider (e.g., via email, network-based application, network communication, SMS message or other electronic techniques via one or more networks, etc.), and (in connection therewith) the issuer 108 may respond with a recommended action plan (or remedial action) and time frame for implementation.

Alternatively in the method 300, if the review engine 118 determines that the performance metrics do satisfy the defined threshold (at 308), the review engine 118 instead advises the service provider that the threshold has been satisfied, at 316, as well as details of the measured performance metric. The advisement, in this scenario, however, typically would not include a remedial action, a consequence, or a deadline, as no remedial action is generally required based on the measured performance metric satisfying the defined threshold. In this manner, the payment network 106 is able to inform the service provider of the performance metrics, even when the performance metrics are within the defined thresholds.

Finally in the method 300, when the advisement transmitted to the service provider regarding the measured performance metrics includes an associated remedial action, consequence, and deadline, the review engine 118 determines, at 318, if the remedial action has been performed by the deadline. If it has not, the review engine 118 causes, at 320, the consequence to be imposed. In particular, the review engine 118 may deliver the performance metrics, remedial action, consequence and deadline to an administrator associated with the payment network 106 who, in turn, reviews the advisement(s) and imposes the consequence if warranted. In the above example regarding the availability of a vendor solution during a time of cardholder (e.g., consumer 112, etc.) verification, if the defined threshold of 99% is still not satisfied (at 318) after 30 days of issuing the probation letter, a team review may occur to discuss either delisting the service provider from authentication services with the payment network 106 or assessment of a financial penalty to the service provider.

In view of the above, the systems and methods herein provide review of authentication services, implemented in payment networks, at least after certification of the services. The reviewed services, when specific to one or more of the performance metrics herein, permits the payment networks to reduce the instances of performance drop, performance degradation, and/or errant implementation and/or use, etc. of the certified authentication services, etc. In this manner, the performance of the payment network, even when provided by and/or through vendors, is confirmed and verified to be consistent with one or more desired thresholds, thereby promoting quality of service to consumers, merchants, acquirers, issuers, etc.

The foregoing description of exemplary embodiments has been provided for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure. Individual elements or features of a particular embodiment are generally not limited to that particular embodiment, but, where applicable, are interchangeable and can be used in a selected embodiment, even if not specifically shown or described. The same may also be varied in many ways. Such variations are not to be regarded as a departure from the disclosure, and all such modifications are intended to be included within the scope of the disclosure.

It should be appreciated that one or more aspects of the present disclosure transform a general-purpose computing device into a special-purpose computing device when configured to perform the functions, methods, and/or processes described herein.

As will be appreciated based on the foregoing specification, the above- described embodiments of the disclosure may be implemented using computer programming or engineering techniques including computer software, firmware, hardware or any combination or subset thereof, wherein the technical effect may be achieved by performing at least one of: (a) identifying at least one performance metric of an authentication service, the authentication service implemented into a payment network and certified to the payment network; (b) measuring the at least one performance metric of the authentication service; (c) electronically notifying a service provider associated with the authentication service, when the at least one performance metric fails to satisfy a defined threshold; and (d) transmitting to the service provider at least one remedial action for the authentication service and at least one

consequence for failure to satisfy the remedial action, whereby the payment network is configured to monitor the authentication service after certification of the authentication service.

Example embodiments are provided so that this disclosure will be thorough, and will fully convey the scope to those who are skilled in the art.

Numerous specific details are set forth, such as examples of specific components, devices, and methods, to provide a thorough understanding of embodiments of the present disclosure. It will be apparent to those skilled in the art that specific details need not be employed, that example embodiments may be embodied in many different forms, and that neither should be construed to limit the scope of the disclosure. In some example embodiments, well-known processes, well-known device structures, and well-known technologies are not described in detail. In addition, advantages and improvements that may be achieved with one or more exemplary embodiments of the present disclosure are provided for purpose of illustration only and do not limit the scope of the present disclosure, as exemplary embodiments disclosed herein may provide all or none of the above mentioned advantages and improvements and still fall within the scope of the present disclosure.

The terminology used herein is for the purpose of describing particular example embodiments only and is not intended to be limiting. As used herein, the singular forms "a," "an," and "the" may be intended to include the plural forms as well, unless the context clearly indicates otherwise. The terms "comprises,"

"comprising," "including," and "having," are inclusive and therefore specify the presence of stated features, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, steps, operations, elements, components, and/or groups thereof. The method steps, processes, and operations described herein are not to be construed as necessarily requiring their performance in the particular order discussed or illustrated, unless specifically identified as an order of performance. It is also to be understood that additional or alternative steps may be employed.

When an element or layer is referred to as being "on," "connected to," "coupled to," or "in communication with" another element, it may be directly on, connected or coupled to, or in communication with the other element, or intervening elements may be present. In contrast, when an element is referred to as being "directly on," "directly connected to," "directly coupled to," or "directly in communication with" another element, there may be no intervening elements present. As used herein, the term "and/or" includes any and all combinations of one or more of the associated listed items.

Although the terms first, second, third, etc. may be used herein to describe various features, these features should not be limited by these terms. These terms may be only used to distinguish one feature from another. Terms such as "first," "second," and other numerical terms when used herein do not imply a sequence or order unless clearly indicated by the context. Thus, a first feature discussed herein could be termed a second feature without departing from the teachings of the example embodiments.