Engine for configuring access request authentication

Abstract

A method includes a security assessment computer receiving access data from a user device of a user during an access request. The security assessment computer analyzes the access data using authentication rules that each specify one of a plurality of authentication protocols for authenticating the user or the user device. At least one of the authentication rules specifies a security level flag when authentication is not performed. The security assessment computer triggers a first authentication rule corresponding to a first authentication protocol of the plurality of authentication protocols and implements the first authentication protocol. The security assessment computer sends an authorization request message to an authorization server in a manner consistent with the first authentication protocol and then receives an authorization response message. The security assessment computer analyzes the access data and the authorization response message using authorization rules to determine whether to complete the access request.

Description

[0001] Cross-referencing related applications

[0002] This application claims priority to U.S. Provisional Application No. 63 / 050,573, filed July 10, 2020, entitled “Exemption Engine System and Method,” and is a non-provisional application of said U.S. Provisional Application, the entire contents of which are incorporated herein by reference for all purposes. Background Technology

[0003] Unauthorized users may use authorized users' authorization information to fraudulently request access to resources. To prevent unauthorized access, the system can authenticate users before they can access resources.

[0004] As part of providing access to resources, multiple computers may participate in routing and processing electronic communications. For example, authentication checks may be performed to authenticate users and / or authorization checks may be performed. One or more of these checks may be performed by one or more different entities. Difficulties in coordination and communication between these different computers may delay and hinder such processes of providing access to resources.

[0005] Furthermore, different access requests may require different levels of security (e.g., authentication). It is difficult for each resource provider to determine individually whether and to what extent user authentication is required when requesting access to a resource.

[0006] The embodiments of this disclosure address this problem and other problems individually and collectively. Summary of the Invention

[0007] One embodiment relates to a method comprising: receiving access data from a user's user device by a security assessment computer during an access request; the access data then being analyzed using authentication rules, each specifying one of a plurality of authentication protocols for authenticating the user or the user device. At least one of the authentication rules may specify a security level flag when authentication is not performed. After analyzing the access data, a first authentication rule corresponding to a first authentication protocol among the plurality of authentication protocols may be triggered. The first authentication protocol is then implemented. An authorization request message is then sent to an authorization server in a manner consistent with the first authentication protocol. Thereafter, an authorization response message may be received. The access data and the authorization response message may be analyzed using the authorization rules to determine whether the access request has been completed.

[0008] Another embodiment relates to a security assessment computer. The security assessment computer includes a processor and a computer-readable medium coupled to the processor. The computer-readable medium may include code executable by the processor for implementing a method. The method may include the security assessment computer receiving access data from a user's user device during an access request. The security assessment computer then analyzes the access data using authentication rules, each specifying one of a plurality of authentication protocols for authenticating the user or the user device. At least one of the authentication rules specifies a security level flag when authentication is not performed. After analyzing the access data, the security assessment computer may trigger a first authentication rule corresponding to a first authentication protocol among the plurality of authentication protocols, and then implement the first authentication protocol. The security assessment computer may then send the authorization request message to an authorization server in a manner consistent with the first authentication protocol. After sending the authorization request message, the security assessment computer may receive an authorization response message. The security assessment computer may then analyze the access data and the authorization response message using authorization rules to determine whether the access request should be completed.

[0009] Another embodiment relates to a method comprising: receiving access data from a user's user device by a resource provider computer during an access request. The resource provider computer may then generate an authorization request message including the access data to a security assessment computer. The security assessment computer then analyzes the access data using authentication rules, each specifying one of a plurality of authentication protocols for authenticating the user or the user device. At least one of the authentication rules may specify a security level flag when authentication is not performed. The security assessment computer then triggers a first authentication rule corresponding to a first authentication protocol among the plurality of authentication protocols and implements the first authentication protocol. The security assessment computer then sends the authorization request message to an authorization server in a manner consistent with the first authentication protocol and receives an authorization response message. The security assessment computer may also analyze the access data and the authorization response message using the authorization rules to determine whether the access request is completed. If the security assessment computer determines that the access request is completed, the resource provider computer may then receive the authorization response message. Upon receiving the authorization response message, the resource provider computer provides the authorization response message to the user device.

[0010] Further details regarding embodiments of this disclosure can be found in the detailed description and the accompanying drawings. Attached Figure Description

[0011] Figure 1A block diagram of an access request processing system according to an embodiment is shown.

[0012] Figure 2 A block diagram of the components of an exemption engine according to an embodiment is shown.

[0013] Figure 3 A flowchart illustrating the authentication protocol determination and implementation method according to an embodiment is shown.

[0014] Figure 4 A first user interface according to an embodiment is shown.

[0015] Figure 5 A second user interface according to an embodiment is shown.

[0016] Figure 6 A flowchart illustrating the authentication and authorization process according to an embodiment is shown.

[0017] Figure 7 A flowchart illustrating an access request processing method according to an embodiment is shown.

[0018] Figure 8 A block diagram of a computer system according to an embodiment is shown.

[0019] the term

[0020] Before discussing the embodiments of this disclosure, some terms may be described in further detail.

[0021] A “user device” can be a device operated by a user. Examples of user devices can include mobile phones, smartphones, cards, personal digital assistants (PDAs), laptops, desktop computers, server computers, vehicles (e.g., automobiles), simplified client devices, tablet PCs, and so on. Additionally, a user device can be any type of wearable technology device, such as a watch, headphones, glasses, etc. A user device can include one or more processors capable of processing user input. A user device can also include one or more input sensors for receiving user input. As is known in the art, there are various input sensors capable of detecting user input, such as accelerometers, cameras, microphones, etc. User input obtained by input sensors can come from various data input types, including but not limited to audio data, visual data, or biometric data. A user device can include any electronic device that can be operated by the user, and said electronic device can also provide remote communication capabilities with a network. Examples of remote communication capabilities include using mobile phone (wireless) networks, wireless data networks (e.g., 3G, 4G, or similar networks), Wi-Fi, Wi-Max, or any other communication medium that can provide access to a network (e.g., the Internet or a private network).

[0022] An "access device" can be any suitable device that provides access to a remote system. Access devices can also be used to communicate with a coordinating computer, communication network, or any other suitable system. Access devices can typically be located anywhere suitable, such as at the merchant's location. Access devices can take any suitable form. Some examples of access devices include POS or point-of-sale devices (e.g., POS terminals), cellular phones, personal digital assistants (PDAs), personal computers (PCs), tablet PCs, handheld dedicated readers, set-top boxes, electronic cash registers (ECRs), vending machines, automatic teller machines (ATMs), virtual cash registers (VCRs), kiosks, security systems, access systems, etc.

[0023] Access devices can use any suitable contact or contactless operating mode to send or receive data from or associated with mobile communication devices or payment devices. For example, an access device may have a card reader, which may include electrical contacts, radio frequency (RF) antennas, optical scanners, barcode readers, or magnetic stripe readers to interact with portable devices such as payment cards.

[0024] A "resource provider" can be an entity that can provide resources such as goods, services, information, and / or access. Examples of resource providers include merchants, data providers, transportation departments, government entities, site and residential operators, etc.

[0025] The term "resource" generally refers to any asset that can be used or consumed. For example, a resource can be an electronic resource (such as stored data, received data, computer accounts, networked accounts, email inboxes), a physical resource (such as tangible objects, buildings, safes, or physical locations), or other electronic communications between computers (such as communication signals corresponding to accounts used to execute transactions).

[0026] "Access data" can include any suitable data that can be used to access a resource or create data that allows access to a resource. For example, the resource can be a location, and access data can include data that can be used to access that location, such as event ticket information, data for accessing a building, transportation ticket information, etc. As another example, access data can include data that can be used to obtain a resource. As yet another example, access data can be account information for a payment account. Account information can include the primary account number (PAN), payment token, expiration date, verification value, etc.

[0027] The term "access request" generally refers to a request to access a resource. For example, an access request may be received from a requesting computer, user device, or resource computer. An access request may include access data, as described above. An access request may also include access data such as an access request identifier, resource identifier, timestamp, date, device or computer identifier, geographic location, or any other suitable information. An access request can be of any suitable type. For example, an access request may be a data access request, a secure webpage access request, a secure location access request, a transaction request, etc.

[0028] The term "rule" can include any process or definition used to determine the outcome of a rule based on certain criteria. In some embodiments, a rule can include one or more rule conditions and associated rule outcomes. "Rule conditions" can specify a logical expression that describes the circumstances under which the outcome of a rule is determined. The conditions for accessing a rule can relate to an access request for a data element based on a data element having a specific value, based on the value being within a certain range, based on the value being higher or lower than a threshold, or any combination thereof.

[0029] A “credential” can include any evidence of authorization, rights, or privileges. For example, an access credential can include permission to access certain tangible or intangible assets (such as buildings or documents). Instances of credentials can include passwords, passcodes, or confidential messages. In another instance, a payment credential can include any suitable information associated with and / or identifying an account (e.g., a payment account and / or a payment device associated with said account). This information can be directly related to the account or derived from account-related information. Instances of account information can include “account identifiers” such as PAN (primary account number or “account number”), tokens, sub-tokens, gift card numbers or codes, prepaid card numbers or codes, usernames, expiration dates, CVV (card verification value), dCVV (dynamic card verification value), CVV2 (card verification value 2), CVC3 card verification value, and so on. An instance of a PAN is a 16-digit number, such as “41470900 0000 1234”. In some embodiments, credentials can be considered sensitive information.

[0030] The term "verification" and its derivatives can refer to the process of using information to determine whether a potential subject is valid under a given set of conditions. Verification can include any comparison of information to ensure that certain data or information is correct, valid, accurate, legitimate, and / or credible.

[0031] A “flag” can be a value that acts as a signal for a function or process. A security level flag can be a flag that indicates information about a security process. For example, a security level flag can indicate the security level of the data being analyzed (e.g., access data, etc.). In some embodiments, a security level flag can indicate an authentication protocol and / or authentication exemption. For example, a security level flag can instruct a security assessment computer to determine that authentication of the user and / or user device should not be performed. As another example, a security level flag can instruct a security assessment computer to determine that a third authentication protocol should be performed due to decisions regarding the “high risk” or “high value” of the accessed data.

[0032] An "authorization request message" can be an electronic message requesting authorization for an access request. In some embodiments, the message is sent to a transaction processing computer and / or the issuer of a payment card to request authorization for the transaction. According to some embodiments, the authorization request message may comply with International Organization for Standardization (ISO) 8583, a standard for systems that exchange information about electronic transactions associated with payments made by a user using a payment device or payment account. The authorization request message may include an issuer account identifier that can be associated with the payment device or payment account. The authorization request message may also include additional data elements corresponding to "identification information," including (by way of example only): service code, card verification value (CVV), dynamic card verification value (dCVV), primary account number or "account number" (PAN), payment token, username, expiration date, etc. The authorization request message may also include "transaction information," such as any information associated with the current transaction, such as transaction value, merchant identifier, merchant location, acquiring bank identifier (BIN), chip card acceptor ID, information identifying the item being purchased, etc., and any other information that may be used to determine whether to identify and / or authorize the transaction.

[0033] An "authorization response message" can be a message responding to an authorization request. In some cases, an authorization response message can be an electronic message response to an authorization request message generated by the issuing financial institution or transaction processing computer. For example, an authorization response message may include one or more of the following status indicators: approved – the transaction is approved; rejected – the transaction is not approved; or call center – further information is pending, and the merchant must call the toll-free authorization number. An authorization response message may also include an authorization code, which can be a code indicating approval of the transaction returned by the credit card issuing bank to the merchant's access device (e.g., a POS device) in response to the authorization request message in the electronic message (directly or via the transaction processing computer). This code can serve as evidence of authorization.

[0034] "Authorizing entity" can be the entity requesting authorization. Instances of authorizing entities can be issuers, government agencies, document repositories, access administrators, etc. Authorizing entities can operate authorizing entity computers. "Issuer" can refer to a commercial entity (e.g., a bank) that issues and optionally maintains user accounts. Issuers can also issue payment credentials stored on user devices, such as cellular phones, smart cards, tablets, or laptops, to consumers, or in some embodiments to portable devices.

[0035] The term "authentication process" can include a procedure for performing authentication. The authentication process can be used to authenticate a user or user device during an access request. In some embodiments, the authentication process can be active authentication, where the user is prompted to provide authentication data (e.g., a password, a token). In other embodiments, the authentication process can be passive authentication, where the user is not prompted to provide authentication data. In such embodiments, data can be retrieved from the user's computing device (e.g., geolocation data) and compared with expected data.

[0036] The term "authentication data" can include data generated and / or processed in association with authentication. Authentication data can indicate the authentication result (e.g., whether a user has been authenticated). Authentication data can include a code indicating the authentication result ("authentication code"). Authentication data can also include detailed information generated during the authentication process. For example, authentication data can include biometric data used to arrive at the authentication result.

[0037] A “processor” can include means for performing a task. In some embodiments, a processor can include any suitable one or more data computing means. A processor can include one or more microprocessors that work together to perform a desired function. A processor can include a CPU that includes at least one high-speed data processor sufficient to execute program components for performing user and / or system-generated requests. A CPU can be a microprocessor, such as AMD’s Athlon, Duron, and / or Opteron; IBM and / or Motorola’s PowerPC; IBM and Sony’s Cell processors; Intel’s Celeron, Itanium, Pentium, Xeon, and / or XScale; and / or similar processors.

[0038] "Memory" can be any suitable one or more devices capable of storing electronic data. Suitable memory may include a non-transitory computer-readable medium storing instructions that can be executed by a processor to implement a desired method. Examples of memory may include one or more memory chips, disk drives, etc. Such memory can be operated using any suitable electrical, optical, and / or magnetic modes of operation.

[0039] A "server computer" can include a powerful computer or cluster of computers. For example, a server computer can be a mainframe, a small cluster of computers, or a group of servers operating as a single unit. In one instance, a server computer can be a database server coupled to a web server. A server computer can include one or more computing devices and can use any of a variety of computing architectures, arrangements, and compilations to serve requests from one or more client computers. Detailed Implementation

[0040] Determining whether to grant access to a resource can involve multiple stages. First, a security authentication process can be performed to authenticate the user or user device (e.g., based on confirming that the user is the person they claim to be). Subsequently, an authorization process can be performed to authorize access to the resource (e.g., based on resource access data such as payment credentials). Additionally, one or more authentication exemption rules can be enforced. These processes may involve similar datasets and analyses. However, these processes may be performed in a disjoint manner, resulting in duplication of work and unnecessary data storage.

[0041] In ascending authentication, users may be prompted for additional information such as passwords or tokens. However, resource providers are increasingly moving towards risk-based authentication, partly to reduce user inconvenience. In some embodiments, resource providers may perform ascending authentication on each access request unless a security assessment computer determines that an authentication exemption can be utilized. According to an embodiment, resource providers may implement a rule-based system to authenticate users based on details analyzed from access requests. This avoids the need to challenge users to enter additional information.

[0042] Access requests may be selectively sent to an authentication computer for authentication. Sometimes, access requests selected for authentication may be more "risky" or more likely to be fraudulent. However, it is not necessarily the case that selecting an access request for authentication makes it more likely to be fraudulent. Resource providers are feeling the impact of fraudulent access due to their risk-based modeling. Without actual escalation, authorization systems may subject authenticated access requests to increased scrutiny. Increased scrutiny can lead to more false positives, meaning that access may be denied even when the request is not fraudulent.

[0043] The systems and methods disclosed herein provide a security assessment computer that can evaluate access data received from a resource provider's computer to at least determine an authentication protocol to be implemented prior to an authorized access request. For example, the security assessment computer can analyze the access data using authentication rules, each specifying one of a plurality of authentication protocols for authenticating a user or user device. In some embodiments, at least one of the authentication rules specifies a security level flag in which authentication is not performed. The security assessment computer can generate a security level flag based on the received access data. The security assessment computer can then trigger an authentication rule corresponding to a first authentication protocol among the plurality of authentication protocols, and then implement the first authentication protocol.

[0044] Advantageously, the authorizing computer can utilize security level flags, calculations, and / or authentication already performed by the security assessment computer when evaluating access requests. The authorizing computer can reduce or even eliminate the required computation, thereby saving time and computing resources. This, in turn, increases confidence and improves the authorization rate. With the security assessment computer having already determined whether authentication of the user and / or user device should be performed, and with assurances of such authentication, resource providers may be more inclined to attempt to authorize access requests. Furthermore, by utilizing pre-existing authorization request messages to transmit authentication data and / or security level flags, no additional message sending and receiving operations are required on the system.

[0045] Furthermore, the system according to various embodiments provides unconventional routing of messages. Specifically, a security assessment computer may be included within the system to redirect access data, including authorization request messages received from a resource provider computer during an access request, to an authentication server for real-time authentication of the user and / or user device. The authentication server may respond to the security assessment computer with authentication data that can indicate whether the user and / or user device is authentic. The security assessment computer may then include the authentication data along with access data in an authorization request message, which is further provided to the authorization server for authorization. As discussed in more detail herein, unconventional routing of data and messages according to various embodiments provides numerous advantages. For example, the security assessment computer can determine whether to authenticate the user and / or user device during an access request without requiring authentication for every access request.

[0046] I. Access Request Processing System

[0047] Figure 1A block diagram of an access request processing system according to an embodiment is shown. The system may receive a request for access to a resource from a user. The system may include an authentication server for determining whether to authenticate the user. The system may also include an authorization server for determining whether to authorize access to the resource. The system may further include a security assessment computer that analyzes access data and implements an authentication protocol based on the analysis before sending an authorization request to the authorization server.

[0048] System 100 includes user device 102, access device 104, resource provider computer 106, security assessment computer 108, transmission computer 110, network processing computer 112, authorization server 114, and authentication server 116.

[0049] User device 102 can operationally communicate with access device 104 and resource provider computer 106. Resource provider computer 106 can operationally communicate with access device 104 and security assessment computer 108. Security assessment computer 108 can operationally communicate with transmission computer 110 and authentication server 116. Network processing computer 112 can operationally communicate with transmission computer 110 and authorization server, which can operationally communicate with authentication server 116.

[0050] To simplify the explanation, Figure 1 A certain number of components are shown. However, it should be understood that embodiments of the invention may include more than one of each component. Furthermore, some embodiments of the invention may include more than one of each component. Figure 1 All components shown are either fewer or more components.

[0051] Figure 1 At least some computers within the network may transmit messages using secure communication protocols, such as, but not limited to, File Transfer Protocol (FTP), Hypertext Transfer Protocol (HTTP), Secure Hypertext Transfer Protocol (HTTPS), SSL, ISO (e.g., ISO 8583), etc. The communication network may include any one and / or a combination of the following: direct interconnection; the Internet; a local area network (LAN); a metropolitan area network (MAN); an Operational Mission as a Node on the Internet (OMNI); a secure custom connection; a wide area network (WAN); a wireless network (e.g., employing protocols such as, but not limited to, Wireless Application Protocol (WAP), I-mode, etc.); etc. The communication network may use any suitable communication protocol to generate one or more secure communication channels. In some instances, the communication channels may include secure communication channels, which may be established in any known manner, such as by using mutual authentication and session keys, and by establishing a Secure Sockets Layer (SSL) session.

[0052] User device 102 can be in any suitable form. For example, suitable user devices can be handheld and compact, allowing them to fit in a user's pocket. Examples of user device 102 may include any device capable of accessing the Internet. Specific examples of user device 102 include cellular or wireless phones (e.g., smartphones), tablet phones, tablet computers, laptop computers, desktop computers, personal digital assistants (PDAs), pagers, portable computers, smart cards, and the like.

[0053] A user can use user device 102 to request access to resources from a resource provider (e.g., a merchant, etc.). For example, user device 102 can execute an access request using access device 104 or resource provider computer 106. The access request can be a payment transaction (e.g., for purchasing goods or services), a location access request (e.g., for accessing a transportation system), or any other suitable access request (e.g., accessing a secure webpage, accessing a secure location, etc.). User device 102 can interact with access device 104 at a resource provider location associated with resource provider computer 106. For example, a user can tap user device 102 against an NFC reader in access device 104. Alternatively, a user can provide access data to the resource provider electronically, such as in an online access request. For example, user device 102 can transmit access data to resource provider computer 106.

[0054] For example, user device 102 may accept input from a user that includes access data associated with the user's attempt to access a resource. As a non-limiting example, the resource may be a physical resource (e.g., a building or lockbox) or an electronic resource (e.g., a local computer account, digital files or documents, a web database, an email inbox, a payment account, or a website login). For example, access data may include one or more of a username, account, token, password, personal identification number, signature, and / or digital certificate. User device 102 may transmit the access data, in whole or in part, to access device 104.

[0055] Access device 104 may include any suitable computing device for controlling access to the resource. For example, access device 104 may be a point-of-sale device, a lockbox on a door, or a secure website. Access device 104 may receive access data directly or via user device 102 for accessing the resource. Based on the access data, access device 104 may prepare a request for access to the resource. Access device 104 may transmit a request for resource access, including some or all of the received access data, to resource provider computer 106.

[0056] Access device 104 and / or user device 102 may include user input interfaces, such as keypads, keyboards, fingerprint readers, retinal scanners, any other type of biometric reader, magnetic stripe readers, chip card readers, RFID readers, or wireless or contactless communication interfaces, etc.

[0057] In one instance, a user may enter one or more of an account, personal identification number, and / or password into access device 104 to request access to a physical resource (e.g., to unlock a security door to enter a building). Access device 104, or a separate computer operatively connected to access device 104, may generate an access request and send it to resource provider computer 106 to request access to the resource.

[0058] In another example, a user can operate user device 102 to request access to electronic resources (e.g., websites or files). This request can be transmitted from user device 102 to access device 104, which can forward the request to resource provider computer 106. The request can be transmitted wirelessly and can be encrypted. The request can be sent in response to user input or voice commands on a screen, or initiated via gestures, such as tapping a phone on a terminal.

[0059] To authorize an access request, an authorization request message may be generated by the access device 104 or the resource provider computer 106, and then the authorization request message may be forwarded to the security assessment computer 108.

[0060] The security assessment computer 108 can analyze access data using authentication rules, each of which can specify one of a plurality of authentication protocols used to authenticate the user and / or user device 102. At least one of the authentication rules can specify a security level flag. In some cases, for example, the security level flag can indicate that authentication should not be performed. The security assessment computer 108 can trigger a first authentication rule corresponding to a first authentication protocol, and then implement the first authentication protocol.

[0061] The security assessment computer 108 can transmit an authentication request to the authentication server 116 or transmit an authorization request message including a security level flag to the transmission computer 110 based on the authentication protocol.

[0062] For example, security assessment computer 108 sends an authentication request to authentication server 116 to authenticate user and / or user device 102. Authentication server 116 can perform authentication in any suitable manner based on data received in the authentication request message (e.g., user device identifier, access data, etc.). Authentication server 116 can be configured to verify (or authenticate) users, user devices, and / or accounts associated with users. Authentication server 116 can notify authorization server 114 of the result of the authentication process (e.g., an indication of whether the user and / or user device has been authenticated). Authentication server 116 can provide an authentication response message to security assessment computer 108, thereby indicating whether the user and / or user device has been authenticated.

[0063] The security assessment computer 108 can send an authorization request message, including a security level flag and / or authentication result, to the authorization server 114 via the transmission computer 110 and the network processing computer 112. For example, after receiving the authorization request message from the security assessment computer 108, the transmission computer 110 transmits the authorization request message to the network processing computer 112. The network processing computer 112 then forwards the authorization request message to the corresponding authorization server 114 associated with an authorization entity, which is associated with, for example, credentials issued for and / or associated with the user and / or user device 102.

[0064] After receiving the authorization request message, in some embodiments, the authorization server 114 may verify whether the user and / or user device has been authenticated by the authentication server 116. In other embodiments, the authorization server 114 may verify that a security level flag indicates that the authentication protocol used is suitable for accessing data and / or user device 102.

[0065] In another embodiment, the authorization server 114 may determine that a security level flag is associated with an authentication protocol, wherein the user and / or user device 102 does not need to be authenticated. The authorization server 114 may determine that the user and / or user device 102 does not need to be authenticated and may proceed with the access request. In other cases, the authorization server 114 may determine that an authentication protocol should be initiated and may request the security assessment computer 108 and / or the authentication server 116 to perform a specific authentication protocol. The authorization server 114 may determine whether to authorize the access request based on the result of the authentication protocol.

[0066] After generating an authorization response message, the authorization server 114 sends the authorization response message back to the network processing computer 112 to indicate whether to authorize (or not authorize) the current access request. The network processing computer 112 then forwards the authorization response message back to the transport computer 110. In some embodiments, even if the authorization server 114 has authorized the access request, the network processing computer 112 may reject the transaction, for example, based on the value of a fraud risk score and / or any other suitable data.

[0067] After receiving the authorization response message, the transmission computer 110 can send the authorization response message to the security assessment computer 108.

[0068] The security assessment computer 108 can analyze authorization response messages and / or access data using authorization rules to determine whether to complete the access request. For example, the security assessment computer 108 can determine whether the address provided by the user contains correctable errors (e.g., misspelling the word "street" as "streat"). Based on the errors in the provided address, the security assessment computer 108 can determine whether to deny the access request or request further authentication (e.g., if authentication has not yet been performed).

[0069] After the security assessment computer 108 determines that the access request can be made, the security assessment computer 108 can send an authorization response message to the resource provider computer 106.

[0070] After receiving the authorization response message, the resource provider computer 106 may provide the authorization response message to the user device 102 and / or the access device. In some embodiments, the authorization response message or an indication of whether the access request is authorized is displayed by the access device 125, or it may be printed on a physical receipt and provided to the user on the user device 102. Alternatively, if the transaction is an online transaction, the resource provider computer 106 may provide a webpage or other indication of the authorization response message as a virtual receipt. The receipt may include access data used for the access request.

[0071] II. Security Assessment Computer

[0072] A security assessment computer may reside within an access request processing system. The security assessment computer may include an authentication configuration module (e.g., an exemption engine) configured to determine one or more exemptions or other instances that can be skipped or executed for one or more types of authentication. In some embodiments, the security assessment computer may be configured to manage and assess access requests.

[0073] Figure 2A block diagram of a security assessment computer 200 according to an embodiment is shown. The exemplary security assessment computer 200 may include a processor 204. The processor 204 may be coupled to a memory 202, a network interface 206, and a computer-readable medium 208. The computer-readable medium 208 may include an authentication configuration module 208A, a message receiving and sending module 208B, and a post-authorization module 208C. In some embodiments, the security assessment computer 200 may operatively communicate with a rules database 220.

[0074] The security assessment computer 200 can allow resource provider computers to optimize exemptions. For example, the security assessment computer 200 can provide resource providers with a user interface to configure PSD2 SCA exemptions. The security assessment computer 200 may include a multi-component solution utilizing a decision manager rule engine and machine learning models. For example, the security assessment computer 200 provides resource providers with the ability to detect high-risk access requests (e.g., transaction, data access requests, etc.) and equally identify access requests that meet the authentication exemption criteria. Resource providers can configure authentication exemption policies and maintain a balance between risk, user experience, processing costs, and compliance.

[0075] Memory 202 can be used to store data and code. Memory 202 can be coupled internally or externally to processor 204 (e.g., a cloud-based data storage device) and can include any combination of volatile and / or non-volatile memory such as RAM, DRAM, ROM, flash memory, or any other suitable memory device. For example, memory 202 can store security level flags, exemption rules, access data, authorization rules, etc.

[0076] Computer-readable medium 208 may include code executable by processor 204 to perform various methods. For example, computer-readable medium 208 may include code executable by processor 204 to perform methods including receiving access data from a user's device during an access request. The security assessment computer can then analyze the access data using authentication rules, each specifying one of a plurality of authentication protocols for authenticating a user or user device. At least one of the authentication rules may specify a security level flag when authentication is not performed. The security assessment computer may then trigger a first authentication rule corresponding to a first authentication protocol among the plurality of authentication protocols. After triggering the first authentication rule, the security assessment computer may implement the first authentication protocol. The security assessment computer may then send an authorization request message to an authorization server in a manner consistent with the first authentication protocol and then receive an authorization response message. After receiving the authorization response message from the authorization server, the security assessment computer can analyze the access data and the authorization response using authorization rules to determine whether the access request has been completed.

[0077] The authentication configuration module 208A may include code or software executable by the processor 204 to determine an exemption applicable to the access request. For example, the authentication configuration module 208A, in conjunction with the processor 204, may analyze received access data using authentication rules, each specifying one of a plurality of authentication protocols used to authenticate a user or user device. The authentication configuration module 208A, in conjunction with the processor 204, may include code for determining whether to apply an exemption or other rules to skip or perform one or more types of authentication. Exemptions may be applied, allowing the system to skip or perform various authentication operations. Exemptions may be applied based on configurable rules. For example, exemptions may apply to transactions below a threshold, whitelists, risk-based rules, etc. In some embodiments, the authentication configuration module 208A, in conjunction with the processor 204, may also trigger authentication rules corresponding to authentication protocols among a plurality of authentication protocols, and then implement a first authentication protocol.

[0078] The authentication configuration module 208A, in conjunction with the processor 204, can determine a security level flag. The security level flag can be a flag indicating information about the security process. For example, the security level flag can indicate the security level of accessing data. In some embodiments, the security level flag can indicate an authentication protocol and / or authentication exemption. For example, the authentication configuration module 208A, in conjunction with the processor 204, can determine that authentication will not be performed due to exemptions for "low amount," "low risk," etc. The authentication configuration module 208A, in conjunction with the processor 204, can generate a security level flag indicating that authentication will not be performed. The security level flag may include information about the authentication protocol and / or exemption.

[0079] The message receiving module 208B may include code or software executable by the processor 204 for preparing and transmitting messages. The message receiving module 208B, in conjunction with the processor 204, may also be configured to receive and analyze messages (e.g., authentication response messages). The message receiving module 208B may include functionality for generating authentication request messages and authorization request messages. The message receiving module 208B, in conjunction with the processor 204, may prepare messages to include information generated by the authentication configuration module 208A and / or received in authentication response messages (e.g., authentication data). The message receiving module 208B may include functionality for transmitting authentication request messages and authorization request messages.

[0080] The post-authorization module 208C may include code or software executable by the processor 204 for evaluating post-authorization of access requests. In some cases, even though the authorizing computer has granted access to the resource, the post-authorization module 208C, in conjunction with the processor 204, may determine to deny the access request. For example, the authorization operation may reveal that certain credentials are invalid; in this case, the post-authorization module 208C, in conjunction with the processor 204, may determine that post-authorization of the access request should be denied.

[0081] In some embodiments, the security assessment computer 200 may operationally communicate with a rule database 220. The rule database 220 may include any suitable database. The database may be a general-purpose, fault-tolerant, relational, scalable, and secure database, such as one available from Oracle or Sybase. Exemption rules may specify criteria used to identify exemptions associated with an access request. Each of the exemption rules may include one or more conditions corresponding to one or more parameters in the access request. Other rules (in addition to exemption rules) may specify when to perform or skip a particular type of authentication. Embodiments may implement any such rules, including exemption rules.

[0082] The security assessment computer 200 can perform any other suitable security assessment. For example, the security assessment computer 200 can also run an exemption engine during the pre-authorization and post-authorization phases. In some embodiments, the exemption authentication module can allow resource providers to create rules for detecting exemptions. In some embodiments, the security assessment computer 200 can perform access request risk analysis (e.g., transaction risk analysis (TRA)). The TRA can include signals for authorizing entities and acquirers that are outside the scope (e.g., one-leg-out / international payments and MOTO (mail order / telephone order)). In some embodiments, the security assessment computer 200 can also whitelist resource providers (e.g., as trusted beneficiaries). During a security assessment, such as determining whether user authentication is required, the security assessment computer 200 can consider whether the resource provider is whitelisted. The security assessment computer 200 can also allow resource providers to directly process exempted access requests through authorization, which can help resource providers provide a smooth consumer experience and significantly reduce 3DS costs. After the security assessment computer 200 determines that user authentication is not required, it can provide an automatic authentication retry mechanism if the authorized entity requires an SCA.

[0083] Network interface 206 may include an interface that allows security assessment computer 200 to communicate with external computers. Network interface 206 enables security assessment computer 200 to transmit data to and from other devices (e.g., resource provider computers, transmission computers, authentication servers, etc.). Some examples of network interface 206 may include a modem, a physical network interface (e.g., an Ethernet card or other network interface card (NIC)), a virtual network interface, a communication port, a PCMCIA slot and card, etc. Wireless protocols enabled by network interface 206 may include Wi-Fi. TMData transmitted via network interface 206 may be in the form of signals, which may be electrical signals, electromagnetic signals, optical signals, or any other signals that can be received by an external communication interface (collectively, "electronic signals" or "electronic messages"). These electronic messages, which may include data or instructions, may be provided between network interface 206 and other devices via a communication path or channel. As described above, any suitable communication path or channel may be used, such as wires or cables, optical fibers, telephone lines, cellular links, radio frequency (RF) links, WAN or LAN networks, the Internet, or any other suitable medium.

[0084] III. Access Request Processing

[0085] Examples of implementations may use the systems and apparatus described herein to at least execute access requests. During the processing of an access request, various computers may determine whether to authenticate the user, authenticate the user if necessary, and authorize the access request. Figure 3-6 Some examples of such methods are described. In some embodiments, references are made to... Figure 3 The security assessment computer described may include, respectively, Figure 1 and 2 Security assessment computer 108 or security assessment computer 200.

[0086] A. Determination and Implementation of Certification Agreements

[0087] Figure 3 A flowchart illustrating an authentication protocol determination and implementation method according to an embodiment is provided. This will be described within the context of a security assessment computer analyzing access data during an access request. Figure 3 The method illustrated herein. An access request may be initiated by a user device attempting to access resources provided by a resource provider's computer. For example, an access request may include a request to access a secure webpage (e.g., a secure webpage access request). However, it should be understood that the invention can be applied to other types of access requests (e.g., location access requests, payment transactions, data transfers, etc.). In some embodiments, access requests occurring in a specific geographic location (e.g., the United States, California, the European Economic Area, etc.) may default to a specific type of authentication protocol (e.g., ascending authentication, passive authentication, etc.). However, various exemptions may be available, as determined by a security assessment computer, which may indicate the use of different authentication protocols.

[0088] As an illustrative example, a security assessment computer can allow resource providers to configure various exemption and authentication protocol exploits. For instance, a resource provider can configure the security assessment computer's authentication configuration module to apply a first exemption rule before authorizing access requests. This first exemption rule could be that authentication is not required if the access data in the request is below (or above) a specific value (e.g., data limits, data speed, transaction amount, number of items, average item value, etc.).

[0089] At box 302, during an access request between a user's device and a resource provider's computer, the security assessment computer receives an authorization request message from the resource provider's computer. For example, the security assessment computer may receive access data from the user's device during the access request.

[0090] In some embodiments, the authorization request message may include a resource provider identifier that identifies the resource provider or the resource provider's computer. The security assessment computer may retrieve authentication rules for subsequent pre-certification security assessment processes from memory or other suitable databases. The retrieved authentication rules may be associated with the resource provider identifier (e.g., stored in association with the resource provider identifier).

[0091] At box 304, the security assessment computer can perform a pre-authentication security assessment process. Specifically, the security assessment computer can analyze the access data using authentication rules, each specifying one of several authentication protocols used to authenticate a user or user device. At least one of the authentication rules can specify an exemption flag when authentication is not performed. For example, the security assessment computer can utilize exemption qualification 304A, risk rules, and / or machine learning model 304B to determine whether a particular authentication rule applies to the current authorization request message that includes access data.

[0092] Box 304 further instructs the security assessment computer to determine exemplary authentication rules applicable to the current authorization request message. For example, authentication rules may include a trusted list 304C, TRA 304D, MIT 304E, Exit a Branch 304F, and Low / High Risk 304G. A trusted list 304C may be an authentication rule that can be applied to the access request if the user, user device, resource provider, and / or resource provider computer are included in a list of trusted entities. Transaction Risk Analysis (TRA 304D) may be an authentication rule that involves the security assessment computer performing one or more risk analyses based on the authorization request message. In some embodiments, MIT 304E may be an authentication rule that can involve a transaction initiated by a merchant. Exit a Branch 304F may be an authentication rule that involves one or more entities (e.g., users, resource providers, etc.) located in a different geographic location than the remaining entities involved in the access request. The Low / High Risk 304G authentication rule may involve determining whether to classify the access request as low-risk or high-risk based on any suitable characteristics of the access request.

[0093] The security assessment computer can analyze access data and / or authorization request messages that may include, for example, user device identifiers, PANs, tokens, expiration dates, verification values, amounts, etc. The security assessment computer can determine whether authentication rules apply to the received data. In this example, multiple authentication protocols may include a first authentication protocol, a second authentication protocol, and a third authentication protocol.

[0094] For example, after the first authentication protocol is triggered, the security assessment computer can implement the first authentication protocol. For example, if the first authentication protocol is implemented, processing can proceed along path 1A to box 306.

[0095] At box 306, the security assessment computer may send the authorization request message to the authorization server in a manner consistent with the first authentication protocol. For example, the security assessment computer may determine that the amount included in the authorization request message is less than a threshold indicated by the first authentication rule. For example, the amount of data requested by a user for data transfer may be 1GB. The first authentication rule may indicate that authentication is not required if the amount is less than, for example, 2GB. Therefore, the security assessment computer may trigger the first authentication rule corresponding to the first authentication protocol. As another example, the first authentication rule may be a rule that indicates that authentication is not required if the access request is determined to be low-risk based on one or more risk rules and / or machine learning models executed by the security assessment computer.

[0096] If the security assessment computer triggers a first authentication rule corresponding to the first authentication protocol, the security assessment computer can generate a security level flag. The security level flag can indicate the security level of the access request. For example, the security level flag can be related to the triggered first authentication rule and / or the first authentication protocol. In some embodiments, the security level flag can indicate why an exemption from authentication for the user and / or user device is not required. For example, the security level flag can indicate that authentication is not performed due to a low-value exemption, a low-risk exemption, etc.

[0097] In other embodiments, at block 304, the security assessment computer may analyze the access data and trigger a second authentication rule based on the analysis. For example, the second authentication rule may indicate that the risk level determined for the authorization request message indicates the access request is low-risk. However, even if the access request is determined to be low-risk and a low-risk exemption for authentication is available, the second authentication protocol may still instruct authentication to be performed. Furthermore, the security assessment computer may generate a security level flag indicating that the access request is low-risk but authentication of the user and / or user device should still be performed. In some embodiments, the security level flag may indicate a specific type of authentication process for authenticating the user and / or user device. For example, the second authentication protocol may be passively authenticating the user device (e.g., verifying a user device identifier, etc., without requiring further input from the user of the user device).

[0098] After the second authentication protocol is triggered, the security assessment computer can implement it. For example, if the second authentication protocol is implemented, the process can proceed along path 1B to box 308. At box 308, the security assessment computer can communicate with the authentication server to authenticate the user device. For example, the security assessment computer can generate an authentication request message that requests the authentication server to authenticate the user device according to the second authentication protocol indicated by the security level flag.

[0099] At box 311, upon receiving an authentication request message, the authentication server can authenticate the user device according to a second authentication protocol. For example, the authentication server can verify whether the user device identifier or other data from the authorization request message originates from the correct user device. For instance, the user device may have a unique user device identifier known in advance to the authentication server. The authentication server can use a database to verify the user device identifier.

[0100] After authenticating the user device, the authentication server can generate an authentication response message that includes authentication data indicating whether the user device is genuine. The authentication server can then provide the authentication response message to the security assessment computer. Figure 3(Not shown in the image). In other embodiments, the authentication server may provide authentication data, along with other data received from the security assessment computer (e.g., access data, security level flags, etc.), directly to the authorization server.

[0101] Upon receiving an authentication response message, the security assessment computer can determine whether the user device has been authenticated based on the authentication data. If the user device is not authenticated, the security assessment computer can generate an authorization response message indicating that the access request is not authorized and provide the authorization response message to the resource provider computer (not shown). If the user device is authenticated, the security assessment computer can provide an authorization request message to the authorization server in a manner consistent with the second authentication protocol. The authorization request message may include access data, authentication data, and security level flags.

[0102] In another embodiment, at block 304, the security assessment computer may analyze the access data and trigger a third authentication rule based on the analysis. For example, the third authentication rule may indicate that the risk level determined for the authorization request message indicates the access request is high-risk. The third authentication protocol may instruct authentication to be performed because the access request is determined to be high-risk and no authentication exemption is available. Furthermore, the security assessment computer may generate a security level flag indicating that the access request is high-risk and authentication of the user will be performed. In some embodiments, the security level flag may indicate a specific type of authentication process for authenticating the user and / or user device. For example, the third authentication protocol may be an active authentication of the user device (e.g., an ascending authentication method that requires the user to provide information for authentication).

[0103] After the third authentication protocol is triggered, the security assessment computer can implement the third authentication protocol. For example, if the third authentication protocol is implemented, the process can proceed along path 1C to block 310. At block 310, the security assessment computer can communicate with the authentication server to authenticate the user. For example, the security assessment computer can generate an authentication request message that requests the authentication server to authenticate the user device according to the third authentication protocol indicated by the security level flag.

[0104] At box 311, upon receiving an authentication request message, the authentication server can authenticate the user device according to a third authentication protocol. For example, the authentication server can provide an authentication challenge to the user device, challenging the user to authenticate themselves. For instance, the authentication challenge might require the user to input their biometrics (e.g., fingerprint), which the authentication server can verify using pre-stored biometrics. As another example, the authentication server can provide the user with a one-time password via their email address, phone number, etc., and require the user to enter the one-time password into their user device to provide a return to the authentication server for authentication.

[0105] After authenticating the user device, the authentication server can generate an authentication response message that includes authentication data indicating whether the user device is genuine. The authentication server can then provide the authentication response message to the security assessment computer. Figure 3 (Not shown in the image). In other embodiments, the authentication server may directly provide authentication data, along with other data received from the security assessment computer (e.g., access data, security level flags, etc.), to the authorization server. For example, a third authentication protocol may instruct the security assessment computer to provide an authorization request message and an authentication request message to the authentication server. The authentication server may then modify the authorization request message to include authentication data. The authentication server may then provide the modified authorization request message to the authorization server for authorization.

[0106] Upon receiving an authentication response message, the security assessment computer can determine whether the user device has been authenticated based on the authentication data. If the user device is not authenticated, the security assessment computer can generate an authorization response message indicating that the access request is not authorized and provide the authorization response message to the resource provider computer (not shown). If the user device is authenticated, the security assessment computer can provide an authorization request message to the authorization server in a manner consistent with a third authentication protocol. The authorization request message may include access data, authentication data, and security level flags.

[0107] After executing the first authentication protocol at box 306, the second authentication protocol at box 308, or the third authentication protocol at box 310, the security assessment computer provides an authorization request message to the authorization server (unless the user and / or user device authentication fails and the security assessment computer rejects the access request).

[0108] At box 312, the authorization server may receive an authorization request message that includes at least access data. The authorization request message may also include a security level flag and authentication data. Upon receiving the authorization request message, the authorization server may determine whether the security level flag and authentication data (if provided) are sufficient to authorize the access request. The authorization server may determine whether the security level flag indicates an authentication protocol consistent with the access data. For example, the authorization server may determine that a security level flag received from a security assessment computer indicates that authentication should not be performed (e.g., according to a first authentication protocol) because the amount is less than a predetermined threshold.

[0109] In some embodiments, after the security assessment computer determines that authentication should not be performed, the authorization server may evaluate the authorization request message and determine whether to perform authentication. This could be due to any suitable reason, such as a high fraud rate associated with a resource provider, a determined high-risk value associated with the accessed data, etc.

[0110] The authorization server may request the security assessment computer to authenticate the user and / or user device (e.g., via path 2A). For example, the authorization server may generate an authentication request message (or a retry authentication request) that includes access data and any other suitable data. The authorization server may send the authentication request message to the security assessment server. In some embodiments, the authentication request message may indicate a specific authentication protocol (e.g., a second authentication protocol, a third authentication protocol, etc.) for authenticating the user and / or user device. In other embodiments, the authorization server may communicate directly with the authentication server to authenticate the user and / or user device.

[0111] After receiving an authentication request message from the authorization server, the security assessment computer can provide the authentication request message to the authorization server. The authorization server can then continue authenticating the user and / or user device using the indicated authentication protocol. In some embodiments, the authorization server can authenticate the user and / or user device, generate an authentication response message including authentication data, and provide the authentication response message to the authorization server via the security assessment computer.

[0112] In some embodiments, after receiving an authentication response message including authentication data from the authentication server, the security assessment computer may generate an additional authorization request message that includes at least the authentication data. The additional authorization request message may include any other suitable data (e.g., access data, etc.). The security assessment computer may send the additional authorization request message to the authentication server in a manner consistent with the authentication protocol (e.g., a second authentication protocol, a third authentication protocol, etc.).

[0113] Upon receiving an authentication response message, the authorization server can determine whether to authorize the access request based on the authentication response message.

[0114] After determining whether to authorize the access request, processing can proceed along path 2B to box 314. For example, at box 314, the security assessment computer can receive an authorization response message from the authorization server. The authorization response message may include an indication of whether the access request has been authorized.

[0115] At box 316, after receiving the authorization response message, the security assessment computer can analyze the access data and the authorization response message using authorization rules to determine whether to complete the access request. The security assessment computer can perform a post-authorization security assessment. For example, the security assessment computer can assess another set of rules that the resource provider can control to accept or deny the access request after authorization. For example, a post-authorization rule could indicate that if the access request is authenticated and authorized, then the access request is accepted. As another example, a post-authorization rule could indicate that if the access request is authorized, but there are inconsistencies in the geographic location information provided throughout the access request (e.g., the user device location, shipping address, billing address, etc., determined through authentication), then the access request should be denied.

[0116] After determining whether to accept the access request, the security assessment computer can provide an authorization response message to the resource provider computer. The resource provider computer can then notify the user whether the access request was authorized or unauthorized.

[0117] B. User Interface

[0118] Figure 4-5 This illustrates a user interface accessible to the resource provider's computer. The user interface may be hosted and / or provided to the resource provider's computer by a security assessment computer, allowing the resource provider to configure one or more pre-authorization rules and / or post-authorization rules regarding the processing of access requests.

[0119] 1. Pre-authorization rule configuration

[0120] Figure 4 A first user interface according to an embodiment is shown. The first user interface 400 illustrates a rule editor provided from a security assessment computer to a resource provider's computer, enabling the resource provider to configure various authentication and security rules and protocols. For example, the resource provider can configure an execution timing field to determine whether a rule should be executed before an authorized access request. The first user interface 400 can be presented to the resource provider within a configuration file builder.

[0121] The first user interface 400 includes a grouping of exemption rules 402 and a grouping of out-of-scope rules 404. The grouping of exemption rules 402 may include multiple exemption rules 406. For example, the grouping of exemption rules 402 may include a first rule relating to low-risk access requests 408 and a second rule relating to low-value access requests 410. Each rule can be toggled enabled or disabled by the resource provider via an enable toggle button 412. As shown in the first user interface 400, both low-risk access request rule 408 and low-value access request rule 410 are enabled.

[0122] Furthermore, each rule can be associated with an authentication management field 414 that can be configured by the resource provider. As shown in the first user interface 400, the low-risk access request rule 408 is associated with the authentication management option 414 of "Skip Authentication" 416. Therefore, during an access request, if it is determined that the access request is low-risk, the security assessment computer can skip the authentication process (e.g., implement an authentication process in which authentication is not required). The low-value access request rule 410 is associated with the authentication management option 414 of "Authentication" 418. Therefore, during an access request, if it is determined that the access request has a low value 424, the security assessment computer can perform the authentication process even if the low value 424 meets the conditions of the exemption 420 for unauthenticated users.

[0123] Exemption 420 for low value 424 can be defined as any order below a specific value (e.g., less than €30 in a transaction, less than 0.5GB in a data access request, etc.). Exemption 420 for low risk 422 can be a situation where Transaction Risk Analysis (TRA) can be applied. For example, a security assessment computer can determine that an access request is associated with a low-risk issuer or a low-risk acquirer, and can then be considered low-risk 422. In some embodiments, when the resource provider is a trusted resource provider, the security assessment computer can determine that the access request is a low-risk access request 408. For example, a trusted resource provider can present an application to the user on the user's device to initiate the access request. The application itself may require the user to log in or (e.g., via biometrics such as fingerprints or facial features) authenticate itself to the resource provider.

[0124] The grouping of out-of-scope rule 404 may include multiple out-of-scope rules 426. For example, the grouping of out-of-scope rule 404 may include a first rule related to PSD2 exclusion 428, where the access request is a "Leave a branch" 434 request. This rule is associated with an authentication management option 430 of "External Authentication" 432, which can be configured by the resource provider. An access request of the "Leave a branch" 434 type can be an access request where one branch (e.g., a portion) of the access request occurs in a first geographic region, jurisdiction, country, state, city, etc., while the remaining access requests occur in a second geographic region, jurisdiction, country, state, city, etc.

[0125] Compared to the rules and associated exemptions shown in the first user interface 400, there may be additional rules and associated exemptions. For example, various additional exemptions may include access requests initiated by resource providers, recurring access requests, mail orders, telephone orders, access requests from trusted resource providers, security companies, data sharing, etc. For instance, access requests initiated by resource providers may include card-to-wallet transactions, which can be classified as out of scope because the user is not on the resource provider's website or at the resource provider's location when the transaction occurs. Therefore, there may be exemptions that instruct the user not to be authenticated before sending the authorization request message to the authorization server. Recurring access requests may be similar. For example, recurring access requests may occur at a regular rate. The user may not authenticate on the resource provider's website. Mail orders and telephone orders may be similar.

[0126] 2. Post-authorization rule configuration

[0127] Figure 5 A second user interface according to an embodiment is shown. The second user interface 500 illustrates a rule editor provided from a security assessment computer to a resource provider's computer, enabling the resource provider to configure various authentication and security rules and protocols. For example, the resource provider can configure an execution timing field to determine whether a rule is executed before or after authorization.

[0128] The second user interface 500 includes groupings of order data quality rules 502. Each rule can be toggled for monitoring or not monitoring by the resource provider via the monitoring column 504. For example, if the resource provider does not want the security assessment computer to monitor a specific rule, the resource provider can deselect the monitor option for that rule. Furthermore, each rule may include toggle options for Accept 506, Review 508, and Reject 510 to indicate additional options for the rule.

[0129] In addition, each rule in the second user interface 500 includes a score 512, a priority 514, an execution timing option 516, and a rule description 518. For example, the first rule is "Billing and / or delivery address is not verifiable". The resource provider can configure the execution timing option 516 to set when the rule is executed by the security assessment computer. For example, the execution timing field 516 can be selected by the resource provider. Selecting the execution timing field 516 opens a drop-down menu that allows the resource provider to choose between "Before Authorization" 520 or "After Authorization" 522.

[0130] The second user interface 500 also includes a second rule for "correctable errors in the address" and a third rule for "inconsistent geographical location in the request". Resource providers can configure authorization rules using their computers prior to access requests. Resource providers can select an execution timing option 516 for each rule in the second user interface 500.

[0131] Previous negative lists or speed violations allowed resource providers to skip authorization. However, using the second user interface 500, resource providers can configure a pre-authorization flag for any type of rule. If the pre-authorization rule evaluates to true, authorization is skipped, and in some cases, no post-authorization rules are executed.

[0132] Pre-authorization rule evaluation offers several advantages. For example, when a pre-authorization rule denies an access request, the resource provider does not need to continue processing the access request. Furthermore, if the security assessment computer denies an access request during pre-authorization, other computers, such as authorization servers, do not need to process the authorization request message. By doing so, various computers can save computing resources. For example, the authorization server can process other authorization request messages that are likely to have a higher chance of authorization, thus allowing more authorized access requests to be processed with the same amount of computing resources.

[0133] Additionally, if pre-authorization rules reject access requests as transactions, for example, resource providers can avoid unnecessary retention of a user's credit card information.

[0134] Pre-authorization rule evaluation offers additional advantages. For example, pre-authorization rules can provide resource providers with extra control over whether and when to make authorized calls.

[0135] The pre-authorization rule assessment further allows for the evaluation of exemptions for various authentication protocols prior to authorization.

[0136] C. Authorization process with security level markings

[0137] Figure 6 A flowchart illustrating the authentication and authorization process according to an embodiment is shown. Figure 6 The method shown describes an authorization process during which a security assessment computer determines a security level flag. This security level flag may correspond to a specific authentication protocol determined by the security assessment computer, applicable to access requests seeking authorization.

[0138] Prior to step 620, the resource provider computer may access the security assessment computer (e.g., via an application programming interface (API) or other suitable means) to configure one or more authentication rules. For example, before receiving access data, the security assessment computer may receive one or more configurations regarding authentication rules from the resource provider computer. These configurations may include at least one configuration specifying that a first authentication protocol should be processed before the access request is authorized by the authorization server. However, it should be understood that any suitable configuration regarding one or more rules may be provided to the security assessment computer. Furthermore, in some embodiments, the resource provider computer may provide authorization rules regarding the processing of authorization response messages after authorization by the authorization server to the security assessment computer.

[0139] At step 620, user device 602 may provide access data to resource provider computer 604 during the access request. For example, a user of user device 602 may initiate an access request, such as a transaction, using resource provider computer 604. User device 602 may transmit access data, including, for example, account information such as a payment account. Account information may include a primary account number (PAN), payment token, expiration date, verification value, etc.

[0140] At step 622, after receiving access data from user device 602, resource provider computer 604 may generate an authorization request message to authorize the access request. The authorization request message may include the access data and any other suitable data related to the access request. For example, the authorization request message may also include transaction data (e.g., amount, etc.).

[0141] At step 624, after receiving the authorization request message from resource provider computer 604, security assessment computer 606 can analyze the access data using authentication rules. Each authentication rule can specify one of a plurality of authentication protocols used to authenticate a user or user device. In some embodiments, at least one of the authentication rules can specify a security level flag when authentication is not performed.

[0142] As an illustrative example, security assessment computer 606 can determine that the resource provider has previously configured authentication rules such that a first authentication rule can be executed prior to an authorized access request. The first authentication rule can indicate that authentication of the user or user device is not required if the transaction amount is less than (e.g., does not exceed) a threshold. Security assessment computer 606 can determine that the amount included in the authorization request message, such as $10, is less than the threshold of $25.

[0143] Furthermore, authentication rules can specify a security level flag when authentication is not performed. For example, a security level flag can be a data item that indicates the associated authentication rule. A security level flag can also represent a specific exemption for authentication that the security assessment computer determines does not require authentication. In this example, the relevant exemption could be a "low value".

[0144] At step 626, the security assessment computer 606 may trigger a first authentication rule corresponding to a first authentication protocol among a plurality of authentication protocols. For example, the security assessment computer 606 may trigger a first authentication rule indicating that no authentication is required for a purchase of $10.

[0145] At step 628, the security assessment computer 606 may implement the first authentication protocol. For example, the security assessment computer 606 may implement a related authentication protocol, in which case authentication will not be performed.

[0146] At step 630, the security assessment computer 606 may generate an authorization request message and send it to the transmission computer 608. In some embodiments, the security assessment computer 606 may include a security level flag in the authorization request message. For example, the security assessment computer 606 may send the authorization request message in a manner consistent with a first authentication protocol, which may specify that the security level flag is provided to the authorization server 612 when authentication is not performed.

[0147] In step 632, after receiving the authorization request message, the transmission computer 608 may forward the authorization request message to the network processing computer 610.

[0148] At step 634, after receiving the authorization request message from the transmitting computer 608, the network processing computer 610 may transmit the authorization request message to the authorization server 612. In some embodiments, the network processing computer 610 may perform any suitable fraud analysis on the authorization request message before transmitting it to the authorization server 612.

[0149] At step 636, after receiving the authorization request message from network processing computer 610, authorization server 612 can determine whether to authorize the transaction. For example, authorization server 612 can analyze access data and security level flags. Authorization server 612 can determine whether the security level flag indicating that authentication should not be performed due to a low-value exemption (e.g., the exemption applies to the received access data) is accurate. In some embodiments, authorization server 612 can determine that authentication of user and / or user device 602 should be performed. In this case, authorization server 612 can request security assessment computer 606 in conjunction with authentication server ( Figure 6(not shown in the image) to authenticate the user and / or user device 602.

[0150] In other cases, the authorization server 612 can determine whether the security level flags and access data are sufficient to authorize the transaction. The authorization server 612 can generate an authorization response message that includes an indication of whether the transaction has been authorized.

[0151] In step 638, the authorization server 612 may transmit the authorization response message to the network processing computer 610.

[0152] In step 640, after receiving the authorization response message from the authorization server 612, the network processing computer 610 may transmit the authorization response message to the transmission computer 608.

[0153] At step 642, the transmission computer 608 may transmit the authorization response message to the security assessment computer 606.

[0154] At step 644, after receiving the authorization response message, the security assessment computer 606 can analyze the access data and authorization response message using authorization rules to determine whether the access request (e.g., a transaction) has been completed. For example, the security assessment computer 606 can determine whether any rules configured by the resource provider 1) are configured to execute after transaction authorization and 2) apply to the received access data and / or authorization response message.

[0155] For example, security assessment computer 606 may determine that the resource provider has previously configured post-authorization rules that instruct that a transaction be placed in an audit queue if it is associated with a high-risk score. In this example, security assessment computer 606 may determine that the transaction is not associated with a high-risk score and therefore the post-authorization rules configured by the resource provider are not enforced.

[0156] At step 646, the security assessment computer 606 may transmit the authorization response message to the resource provider computer 604.

[0157] At step 648, the resource provider computer 604 may provide an authorization response message or an indication of whether the transaction has been authorized to the user device 602. If the transaction is authorized, the resource provider may provide resources to the user of the user device 602.

[0158] D. Exemplary Access Request Handling Method

[0159] Figure 7 A flowchart illustrating an access request processing method according to an embodiment is shown. Figure 7The method shown can be performed by a security assessment computer during an access request between a user on a user device and a resource provider's computer. However, it should be understood that the invention can be applied to other situations where the access request is a data request, a resource access request, a secure location access request, etc.

[0160] At step 702, the security assessment computer may receive access data from the user's user device during the access request. For example, the access data may include data that can be used to obtain resources. As another example, the access data may be account information for a payment account. Account information may include the primary account number (PAN), payment token, expiration date, verification value, etc.

[0161] At step 704, the security assessment computer can analyze the access data using authentication rules. For example, the security assessment computer can analyze the access data using authentication rules. Each authentication rule can specify one of multiple authentication protocols used to authenticate users and / or user devices. In some embodiments, at least one of the authentication rules can specify a security level flag when authentication is not performed.

[0162] At step 706, after analyzing the access data, the security assessment may trigger a first authentication rule. In some embodiments, the first authentication rule corresponds to a first authentication protocol among a plurality of authentication protocols.

[0163] At step 708, the security assessment computer may implement a first authentication protocol. The first authentication protocol may include any suitable authentication protocol. For example, implementing the first authentication protocol may include determining authentication rules for the first authentication protocol that specify a security level flag when authentication is not performed. The first authentication protocol may instruct unauthenticated users.

[0164] At step 710, after implementing the first authentication protocol, the security assessment computer may send an authorization request message to the authorization server in a manner consistent with the first authentication protocol. For example, the first authentication protocol may specify that a security level flag is included in the authorization request message. Upon receiving the authorization request message, the authorization server may determine, as specified by the security level flag, an authorization access request without authenticating the user and / or user device. In some embodiments, the authorization server may determine the authorization access request in part based on received authentication data (e.g., whether authentication was performed) and the security level flag. The security assessment computer may then generate an authorization response message and transmit the authorization response message to the security assessment computer.

[0165] At step 712, the security assessment computer may receive an authorization response message. For example, the security assessment computer may receive an authorization response message from an authorization server in response to an authorization request message. In some embodiments, the authorization response message may include an indication of whether the access request is authorized.

[0166] At step 714, the security assessment computer can analyze the access data and authorization response messages using authorization rules to determine whether the access request should be completed. For example, the security assessment computer can utilize authorization rules previously configured by the resource provider's computer to determine whether the access request should be completed based on whether the access data and / or authorization response messages meet criteria (e.g., low risk value, low monetary value, consistency throughout the access request, etc.).

[0167] IV. Computer Systems

[0168] Any computer system mentioned in this article can utilize any suitable number of subsystems. Figure 8 An example of such a subsystem in computer system 10 is illustrated. In some embodiments, the computer system includes a single computer device, wherein the subsystem may be a component of the computer device. In other embodiments, the computer system may include multiple computer devices having internal components, each of which is a subsystem. The computer system may include desktop and laptop computers, tablet computers, mobile phones, and other mobile devices.

[0169] Figure 8 The subsystems shown are interconnected via system bus 75. Additional subsystems are shown, such as printer 74, keyboard 78, storage device 79, monitor 76 coupled to display adapter 82 (e.g., display screen, such as LED), etc. Peripheral devices and I / O devices coupled to input / output (I / O) controller 71 can be connected to the computer system via various components known in the art, such as input / output (I / O) ports 77 (e.g., USB, etc.). For example, I / O port 77 or external interface 81 (e.g., Ethernet, Wi-Fi, etc.) can be used to connect computer system 10 to a wide area network (e.g., the Internet), a mouse input device, or a scanner. Interconnection via system bus 75 allows central processing unit 73 to communicate with each subsystem and control the execution of multiple instructions from system memory 72 or storage device 79 (e.g., a fixed disk, such as a hard disk drive or optical disk), as well as the exchange of information between subsystems. System memory 72 and / or storage device 79 may embody computer-readable media. Another subsystem is a data collection device 85, such as a camera, microphone, accelerometer, etc. Any data mentioned herein can be output from one component to another and can be output to the user.

[0170] A computer system may include multiple identical components or subsystems connected together, for example, via an external interface 81, an internal interface, or via a removable storage device that can be attached to and removed from one component to another. In some embodiments, the computer system, subsystem, or device may communicate via a network. In such cases, one computer may be considered a client and another computer a server, where each computer may be part of the same computer system. The client and server may each include multiple systems, subsystems, or components.

[0171] The embodiments of this disclosure have many advantages. For example, various embodiments provide the ability of a resource provider computer, in conjunction with a security assessment computer, to control authentication protocols based on data about the currently processed access request (e.g., access data).

[0172] Furthermore, the security assessment computer advantageously provides one or more user interfaces that resource providers can utilize to influence whether and when specific rules are enforced. For example, a resource provider can configure the security assessment computer to evaluate specific rules before or after the authorization of an access request.

[0173] Without such control over the configuration of various rules, each different resource provider would need to perform additional processing individually to determine whether an access request requires authentication and how strong that authentication should be. This places a heavy burden on resource providers, who need to make these individual decisions in real time during the access request process. In other cases, without the control provided by the embodiments, resource providers could determine whether to implement strong authentication for each access request. However, this is not optimal because resource providers are consuming additional computing resources (e.g., computing power) when authentication may not be necessary. This can further slow down the entire access request system, as too many irrelevant authentication requests can overload the system.

[0174] Various embodiments offer advantages over such systems by being able to determine the security level flags of an access request during the access request process prior to authorization from the user or user device. This real-time determination can prevent erroneous and irrelevant authentication request messages.

[0175] Although the steps in the flowcharts and process flows described above are shown or described in a specific order, it should be understood that embodiments of the invention may include methods with steps in a different order. Furthermore, steps may be omitted or added, and these steps may still be within the scope of embodiments of the invention.

[0176] Various aspects of the embodiments may be implemented using hardware circuitry (e.g., application-specific integrated circuits or field-programmable gate arrays) and / or in a modular or integrated manner using computer software in the form of control logic via a generally programmable processor. As used herein, a processor may include a single-core processor, a multi-core processor on the same integrated chip, or multiple processing units on a single circuit board or networked, as well as dedicated hardware. Based on the disclosure and teachings provided herein, those skilled in the art will recognize and understand other ways and / or methods of implementing the embodiments of this disclosure using hardware and combinations of hardware and software.

[0177] Any software component or function described in this application may be implemented as processor-executable software code using any suitable computer language such as Java, C, C++, C#, Objective-C, Swift, or a scripting language such as Perl or Python, employing conventional or object-oriented techniques. The software code may be stored as a series of instructions or commands on a computer-readable medium for storage and / or transmission. Suitable media include random access memory (RAM), read-only memory (ROM), magnetic media (e.g., hard disk drive or floppy disk), or optical media (e.g., optical disc (CD) or DVD (Digital Universal Disc)), flash memory, etc. The computer-readable medium may be any combination of such storage or transmission means.

[0178] Such programs can also be encoded and transmitted using carrier signals suitable for transmission over wired, optical, and / or wireless networks conforming to various protocols, including the Internet. Therefore, computer-readable media according to embodiments of the invention can be created using data signals encoded with such programs. Computer-readable media encoded with program code can be packaged with a compatible device or provided separately from other devices (e.g., downloaded via the Internet). Any such computer-readable medium can reside on or within a single computer product (e.g., a hard disk drive, CD, or an entire computer system) and can exist on or within different computer products within a system or network. A computer system may include a monitor, printer, or other suitable display for providing a user with any of the results mentioned herein.

[0179] Any method described herein can be performed wholly or partially by a computer system including one or more processors configured to perform the steps. Therefore, embodiments may relate to computer systems configured to perform steps of any method described herein, possibly having different components that perform corresponding steps or groups of corresponding steps. Although presented as numbered steps, the steps of the methods herein may be performed simultaneously or at different times or in different orders. Furthermore, portions of these steps may be used in conjunction with portions of other steps of other methods. Additionally, all or part of the steps may be optional. Furthermore, any step of any method may be performed using other components of a module, unit, circuit, or system for performing those steps.

[0180] Specific details of particular embodiments may be combined in any suitable manner without departing from the spirit and scope of embodiments of this disclosure. However, other embodiments of this disclosure may relate to specific embodiments associated with each individual aspect or a particular combination of these individual aspects.

[0181] The above description is illustrative and not restrictive. Many variations of the invention will become apparent to those skilled in the art upon reading this disclosure. Therefore, the scope of the invention should not be determined by reference to the above description, but rather by reference to the pending claims and their full scope or equivalents.

[0182] Without departing from the scope of the invention, one or more features of any embodiment may be combined with one or more features of any other embodiment.

[0183] Unless explicitly indicated otherwise, the use of “a,” “an,” or “the” is intended to indicate “one or more.” Unless explicitly indicated otherwise, the use of “or” is intended to indicate “inclusive or,” not “exclusive or.” A reference to the “first” component does not necessarily require the provision of the second component. Furthermore, unless explicitly stated otherwise, a reference to the “first” or “second” component does not limit the referenced component to a particular location. The term “based on” is intended to mean “at least partially based on.”

[0184] All patents, patent applications, publications, and descriptions mentioned in this document are incorporated herein by reference in their entirety for all purposes. This is not an admission that they are prior art.

Claims

1. A method comprising: The security assessment computer receives access data from the user's user device during the access request process; The access data is analyzed using authentication rules, each of which specifies one of a plurality of authentication protocols for authenticating the user or the user device, wherein at least one of the authentication rules specifies a security level flag when authentication is not performed. Trigger the first authentication rule corresponding to the first authentication protocol among the plurality of authentication protocols; Implementing the first authentication protocol, wherein implementing the first authentication protocol further includes: The authentication rules of the first authentication protocol specify the security level flag when performing authentication; Generate an authentication request message that includes a request to authenticate the user or the user device; The authentication request message is sent to the authentication server, wherein the authentication server authenticates the user or the user device according to the first authentication protocol, and generates an authentication response message including authentication data indicating whether the user or the user device has been authenticated; Receive the authentication response message; and The security level flag and the authentication data will be included in the authorization request message during the authentication process. The authorization request message is sent to the authorization server in a manner consistent with the first authentication protocol; Receive authorization response message; and The access data and the authorization response message are analyzed using authorization rules to determine whether the access request has been completed.

2. The method of claim 1, wherein the authorization server determines, as specified by the security level flag, whether to authorize the access request without authenticating the user or the user device, generates the authorization response message including an indication of whether the access request is authorized, and transmits the authorization response message to the security assessment computer.

3. The method of claim 1, wherein the authorization server determines, as specified by the security level flag, not to authorize the access request without authenticating the user or the user device, generates a retry authentication request instructing the authentication of the user or the user device, and transmits the retry authentication request to the security assessment computer.

4. The method according to claim 3, further comprising: Receive the retry authentication request; Trigger the second authentication rule corresponding to the second authentication protocol among the plurality of authentication protocols; Implement the second authentication protocol; as well as The additional authorization request message is sent to the authorization server in a manner consistent with the second authentication protocol.

5. The method of claim 1, wherein the authorization server determines the authorization of the access request in part based on the authentication data and the security level flag, generates the authorization response message including an indication of whether the access request is authorized, and transmits the authorization response message to the security assessment computer.

6. The method of claim 1, wherein the authentication request message includes the access data.

7. The method according to claim 1, further comprising: Before receiving the access data, the security assessment computer receives one or more configurations regarding the authentication rules from the resource provider computer.

8. The method of claim 1, wherein implementing the first authentication protocol further comprises: The authentication rule of the first authentication protocol specifies the security level flag when authentication is not performed; as well as The security level flags will be included in the authorization request message when authentication is not performed.

9. A security assessment computer, comprising: processor; as well as A computer-readable medium coupled to the processor, the computer-readable medium including code executable by the processor to perform a method comprising: Receive access data from the user's user device during the access request; The access data is analyzed using authentication rules, each of which specifies one of a plurality of authentication protocols for authenticating the user or the user device, wherein at least one of the authentication rules specifies a security level flag when authentication is not performed. Trigger the first authentication rule corresponding to the first authentication protocol among the plurality of authentication protocols; Implementing the first authentication protocol, wherein implementing the first authentication protocol further includes: The authentication rules of the first authentication protocol specify the security level flag when performing authentication; Generate an authentication request message that includes a request to authenticate the user or the user device; The authentication request message is sent to the authentication server, wherein the authentication server authenticates the user or the user device according to the first authentication protocol, and generates an authentication response message including authentication data indicating whether the user or the user device has been authenticated; Receive the authentication response message; and The security level flag and the authentication data will be included in the authorization request message during the authentication process. The authorization request message is sent to the authorization server in a manner consistent with the first authentication protocol; Receive authorization response message; and The access data and the authorization response message are analyzed using authorization rules to determine whether the access request has been completed.

10. The security assessment computer of claim 9, wherein analyzing the access data and the authorization response message using the authorization rule to determine whether the access request is completed further comprises: Determine whether one of the authorization rules applies to the access data and / or the authorization response message; as well as Determine whether the access data and / or the authorization response message meet the criteria specified by the authorization rules.

11. The security assessment computer of claim 9, wherein the method further comprises: Before receiving the access data, the system receives one or more configurations of the authentication rules and the authorization rules regarding the processing of the authorization response message after authorization is granted by the authorization server to the security assessment computer.

12. The security assessment computer of claim 9, wherein the access request is a data access request, a secure webpage access request, or a secure location access request.

13. The security assessment computer of claim 9, wherein the access data is received from a resource provider's computer, and wherein after analyzing the access data and the authorization response message using the authorization rules to determine whether the access request has been completed, the method further comprises: The authorization response message is sent to the resource provider's computer.

14. The security assessment computer of claim 9, wherein the method further comprises: Retrieve from memory the authentication rule associated with the resource provider identifier received along with the access data.

15. The security assessment computer of claim 9, wherein the access data is received in the authorization request message, and wherein the method further comprises: Before sending the authorization request message, the security assessment computer modifies the authorization request message to include the security level flag.

16. A method comprising: Access data is received from the user's user device by the resource provider's computer during the access request; An authorization request message is generated by the resource provider's computer, the authorization request message including access data to a security assessment computer, wherein the security assessment computer: The access data is analyzed using authentication rules, each specifying one of a plurality of authentication protocols used to authenticate the user or the user device, wherein at least one of the authentication rules specifies a security level flag when authentication is not performed. Trigger the first authentication rule corresponding to the first authentication protocol among the plurality of authentication protocols. Implementing the first authentication protocol, wherein implementing the first authentication protocol further includes: The authentication rules of the first authentication protocol specify the security level flag when performing authentication; Generate an authentication request message that includes a request to authenticate the user or the user device; The authentication request message is sent to the authentication server, wherein the authentication server authenticates the user or the user device according to the first authentication protocol, and generates an authentication response message including authentication data indicating whether the user or the user device has been authenticated; Receive the authentication response message; and The security level flag and the authentication data will be included in the authorization request message during the authentication process. The authorization request message is sent to the authorization server in a manner consistent with the first authentication protocol. Receive authorization response message, and The access data and the authorization response message are analyzed using authorization rules to determine whether the access request should be completed. If the security assessment computer determines that the access request has been completed, the resource provider computer receives the authorization response message; and The authorization response message is provided to the user device by the resource provider's computer.

17. The method of claim 16, further comprising: Before providing the access data, the resource provider computer provides one or more configurations regarding the authentication rules to the security assessment computer.

18. The method of claim 17, wherein the one or more configurations include at least one configuration specifying that the first authentication protocol should be processed before authorizing the access request with the authorization server.

19. The method of claim 16, further comprising: Before providing the access data, the resource provider computer provides the authorization rules regarding the processing of the authorization response message after authorization by the authorization server to the security assessment computer.

20. A computer, comprising: processor; as well as A computer-readable medium coupled to the processor, the computer-readable medium comprising code executable by the processor to perform the method according to any one of claims 1 to 8 and 16 to 19.

Images