Pre-authorization access request screening

Abstract

Describe systems and methods for screening pre-authentication access requests. A server computer may receive a resource access request including access data. The server computer may transmit an authentication request message including at least a subset of the access data to an authentication computer and receive an authentication response message including authentication data. The server computer may determine an access score based on the authentication data. Alternatively, the server computer may determine the access score based on the access data without using / receiving authorization data. The server computer may generate an access indicator based on the access score. The server computer may prepare and transmit an authorization request message including the access indicator to an authorization computer. The authorization computer may approve or deny the access to the resource based on the access indicator.

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims priority to U.S. Provisional Application No. 62 / 712,909, filed on Jul. 31, 2018, the content of which is incorporated herein by reference in its entirety. Background Art

[0003] Unauthorized users may use the authorization information of authorized users to deceptively request access to resources. To prevent unauthorized access, the system can use access rules to perform fraud checks to reject access requests with certain parameters indicated as fraudulent.

[0004] As part of providing resource access, multiple computers can participate in routing and processing electronic communications. For example, authentication checks can be performed to authenticate users, fraud checks can be performed, and / or authorization checks (e.g., based on data such as payment vouchers) can be performed. One or more of these checks can be performed by one or more different entities. The coordination and communication difficulties between these different computers can delay and obstruct such processes of providing resource access.

[0005] The embodiments, alone and in combination, solve these and other problems. Summary of the Invention

[0006] Embodiments include methods and systems for performing fraud checks and / or authentication operations before authorization. The results of such pre - authorization access request screening can be transmitted to an authorization computer for determining whether to grant access to a resource.

[0007] One embodiment relates to a method, including: receiving, by a server computer, a request for access to a resource, the request including access data; determining, by the server computer, an access score based on the access data; generating, by the server computer, an access indicator based on the access score; preparing, by the server computer, an authorization request message including the access indicator; and transmitting, by the server computer, the authorization request message including the access indicator to an authorization computer; wherein the authorization computer approves or rejects access to the resource based on the access indicator included in the authorization request message.

[0008] Another embodiment relates to a system that includes a computer programmed to perform the above - described method.

[0009] Another embodiment relates to a computer product that stores multiple instructions for performing the above - described method.

[0010] Another embodiment relates to a method that includes: receiving, by a server computer, a request for access to a resource, the request including access data; transmitting, by the server computer, an authentication request message to an authentication computer, the authentication request message including at least a subset of the access data; receiving, by the server computer, an authentication response message from the authentication computer, the authentication response message including authentication data, wherein the authentication computer generates the authentication data based on the access data; and determining, by the server computer, an access score based on the authentication data.

[0011] Another embodiment relates to a system that includes a computer programmed to perform the above method. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 Illustrates a system for screening pre - authorization access requests according to some embodiments.

[0013] Figure 2A Illustrates a block diagram of a server computer according to some embodiments.

[0014] Figure 2B Illustrates a block diagram of an authentication computer according to some embodiments.

[0015] Figure 3 Illustrates an example set of operations for authentication and authorization using an authentication code and an authentication password according to some embodiments.

[0016] Figure 4 Illustrates an example set of operations for authentication and authorization according to some embodiments, wherein the authentication code is risk - related.

[0017] Figure 5 Illustrates an example set of operations for authentication and authorization using data fields to convey supplementary data according to some embodiments.

[0018] Figure 6 Illustrates an example set of operations for authentication and authorization using an access indicator according to some embodiments.

[0019] Figure 7 Illustrates an example set of operations for authentication and authorization using an access indicator that provides a guarantee according to some embodiments.

[0020] Figure 8 Illustrates an example set of operations for screening pre - authorization access requests using an access indicator according to some embodiments.

[0021] Figure 9 Illustrates an example set of operations for screening pre - authorization access requests using authorization data according to some embodiments.

[0022] Figure 10Illustrates an example set of operations for screening pre - authorization access requests with exemptions according to some embodiments.

[0023] Figure 11 Illustrates an example set of operations for screening pre - authorization access requests without exemptions according to some embodiments.

[0024] Figure 12 Illustrates an example set of operations for screening pre - authorization access requests with exemptions combined with hybrid authentication according to some embodiments.

[0025] Figure 13 Illustrates an example set of operations for screening pre - authorization access requests with exemption overrides according to some embodiments.

[0026] Figure 14 Illustrates a block diagram of a computer device according to some embodiments.

[0027] Term

[0028] Before discussing the various embodiments, a description of some terms may help provide a better understanding.

[0029] The term "user" may refer to an individual or an entity. A user can be a person interacting with a user computing device (e.g., a mobile phone or a tablet). A user can be a consumer or a business associated with an account, and the account can be used to conduct transactions, including payment transactions.

[0030] The term "user computing device" may refer to a device that can be used to communicate with another device or system. It can include a user computing device for conducting transactions. The user computing device is capable of communicating over a network. The user computing device can take any suitable form. For example, a suitable user computing device can be handheld and compact so that it can be placed in the user's wallet and / or pocket (e.g., it can be pocket - sized). The user computing device can include a processor, as well as a memory, an input device, and an output device operatively coupled to the processor. Specific examples of user computing devices include cellular phones or mobile phones, tablet computers, desktop computers, personal digital assistants (PDAs), pagers, portable computers, smart cards, etc. Additional user computing devices can include wearable devices such as smartwatches, glasses, fitness bands, anklets, rings, earrings, etc. In some embodiments, the user computing device can include a car with remote communication capabilities.

[0031] The term "user data" may include data about the user. User data can include name, mailing address, shipping address, phone number, payment account number, date of birth, marital status, income, social security number, demographic data, etc. In some embodiments, user data can also include user preferences, notification methods, and previous transaction history.

[0032] 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, network accounts, email inboxes), a physical resource (such as a tangible object, building, safe, or physical location), or other electronic communication between computers (such as a communication signal corresponding to an account used to perform a transaction).

[0033] An "access device" can be any suitable device for obtaining access to a resource. The access device can generally be located at any suitable location, such as at the location of a merchant. The access device can be in any suitable form. Some examples of access devices include point-of-sale (POS) devices, cellular phones, personal digital assistants (PDAs), personal computers (PCs), tablet computers, handheld dedicated readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), information kiosks, security systems, access systems, websites, etc. The access device can use any suitable contact or non-contact operation mode to send and receive data from and / or associated with a payment device and / or a portable device.

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

[0035] The term "access request" generally refers to a request to access a resource. For example, an access request can be received from a requesting computer, a user device, or a resource computer. The access request can include access data as described above. The access request can also include access data, such as an access request identifier, a resource identifier, a timestamp, a date, a device or computer identifier, a geographical location, or any other suitable information.

[0036] The term "access rule" can include any process or definition for determining an access rule result based on certain criteria. In some embodiments, the rule can include one or more rule conditions and associated rule results. A "rule condition" can specify a logical expression that describes the circumstances based on which the result of the rule is determined. The conditions of an access rule can relate to access request data elements, based on the data element having a specific value, based on the value being within a certain range, based on the value being above or below a threshold, or any combination thereof.

[0037] The term "identifier" may refer to any information that can be used to identify information. In some embodiments, an identifier can be a special value that is randomly generated or generated according to a predetermined algorithm, code, or shared secret. For example, an authorized entity identifier can be a value or number associated with an authorized entity (e.g., a bank identification number). In another example, an account identifier can be used to uniquely identify an account. In some embodiments, an identifier can be one or more graphics, tokens, barcodes, Quick Response (QR) codes, or any other information that can be used to uniquely identify an entity.

[0038] The term "transaction" may include an exchange or interaction between two entities. In some embodiments, a transaction may refer to a value transfer between two users (e.g., individuals or entities). A transaction may involve an exchange of monetary funds between two individuals or entities, or an exchange of goods or services for monetary funds. In other embodiments, a transaction can be a purchase transaction in which an individual or entity purchases goods or services from a merchant or other entity in exchange for monetary funds. In other embodiments, a transaction can be a non-financial transaction, such as an exchange of data or information between two entities, such as a data transfer. Examples of non-financial transactions may include transactions to verify a user's age or identity (e.g., verify identity through a government agency, verify age for purchasing alcoholic beverages) to access a computer system or a premises.

[0039] The term "message" may include any data or information that can be transmitted from one entity to another entity (e.g., from one computing device to another computing device). A message can be communicated internally between devices / components within a computer or computing system, or externally between devices via a communication network. Additionally, a message can be modified, changed, or otherwise altered to include encrypted or anonymized information.

[0040] "Risk level" may include the result of a risk analysis or assessment. A risk level can be in the form of a numerical or alphanumeric value, such as a number from 1 - 10 or letters from A - Z. A risk level can indicate, for example, the relative degree of risk in a particular situation of a transaction. In some cases, a higher risk level may indicate a high risk, while a lower risk level may indicate a low risk.

[0041] The term "initiate" may include the first step taken to start a process, or the steps taken to complete a process. For example, "initiating the authorization process of a transaction" may refer to the actual process required to authorize a transaction. However, "initiating the authorization process of a transaction" may also refer to the process of sending a message with instructions for the process required to execute an authorized transaction from one computer to another computer.

[0042] The term "authorization process" may include a process for authorizing access to a resource. In some embodiments, the authorization process involves an authorization computer associated with the resource. In some embodiments, the authorization process may involve generating and sending an authorization request message to the authorization computer to authorize a user's access to a resource associated with the authorization computer, and an authorization response message from the issuer computer indicating authorization or denial of the access request.

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

[0044] The term "authentication data" may refer to data generated and / or processed in association with authentication. The authentication data may indicate an authentication result (e.g., whether a user has been authenticated). The authentication data may include a code indicating the authentication result ("authentication code"). The authentication data may also include details generated during the authentication process. For example, the authentication data may include biometric data used to arrive at the authentication result. Detailed Description

[0045] Determining whether to grant access to a resource may involve multiple stages. First, a security authentication process may be performed to authenticate the user (e.g., based on confirming that the user is who they claim to be). Subsequently, an authorization process may be performed to authorize access to the resource (e.g., based on resource access data such as payment credentials). Additionally, one or more fraud checks may be performed. These processes may involve similar data sets and analysis. However, the processes may be performed in a disjoint manner, resulting in duplicate work and unnecessary data storage.

[0046] In escalating authentication, the user may be prompted to enter additional information such as a password or a token. However, resource providers are increasingly moving to risk-based authentication, partly to reduce the hassle for users. Resource providers may implement a rule-based system to authenticate users based on analyzing details of the access request. This may avoid the need to challenge the user to enter additional information. Risk-based authentication may involve generating a rich data set.

[0047] Optionally, an access request may be sent to an authentication computer for authentication. Sometimes, the access requests selected for authentication may be more "risky" or more likely to be fraudulent. However, it is not necessarily the case that just because an access request is selected for authentication that the access request is more likely to be fraudulent. Resource providers are under pressure to be responsible for fraudulent access due to the use of risk-based modeling. In the absence of an actual escalation, the authorization system may subject authenticated access requests to increased scrutiny. Increased scrutiny results in more false positives, i.e., unauthorized access even when the request is not fraudulent.

[0048] The systems and methods disclosed herein provide access indicators for an authorizing entity, such as an issuer, to use in determining whether to grant a user access to a resource. An access indicator may be generated based on received access data. The system may determine a risk level associated with the access request. Such risk analysis may involve using a set of prediction rules. These rules may be applied to the access data to arrive at an access score that quantifies the risk level of the access request.

[0049] Based on the access score, the access indicator may or may not be passed to the authorizing entity. The system may determine whether to pass the access indicator by comparing the access score (i.e., the risk level) to a threshold. For example, the system may use a threshold representing an acceptable value of the access score. If the access score meets or exceeds the threshold, the system may pass the access indicator to the authorizing entity. The access indicator may be passed to the authorizing entity, for example, by including a flag in a specific field of an authorization request message sent to the authorizing entity. The presence of the flag may indicate to the authorizing entity that the access request has passed a risk screening and / or should be approved.

[0050] In some embodiments, the system may utilize authentication data generated by an authentication computer to determine whether to authenticate the user. As examples of authentication data, the authentication computer may generate an authentication code (e.g., a numerical value indicating whether the user is authenticated), an authentication password (e.g., a password that uniquely identifies the authenticated access request), data generated during a risk-based authentication process (e.g., details of the user's past activities), etc. This authentication data may be used to determine the access score and / or the access indicator.

[0051] Advantageously, the authorization computer may utilize the data and computations that have already been performed during the authentication and / or risk screening process of evaluating the access request. The authorization computer is able to reduce or even eliminate the amount of computation required, thus saving time and computational resources. This in turn may increase confidence and improve the authorization rate. The resource provider may be more inclined to authorize the access request when confident that a trusted entity has screened the access request for fraud. Additionally, by using a pre-existing authorization request message to convey authentication and / or risk data, the system is not burdened with additional messaging operations.

[0052] I. Pre - authorization Access Request Screening System

[0053] A. System Overview

[0054] Figure 1 An overview of a system for pre - authorization access request screening is shown. The system can receive requests from users to access resources. The system can include an authentication computer for determining whether to authenticate the user. The system can also include an authorization computer for determining whether to authorize access to the resources. The system can further include a server computer that performs risk checks and transmits applicable information, such as access indicators, to the authorization computer.

[0055] Figure 1 The system 100 in [reference] includes a user computing device 102, an access device 108, a server computer 104, an access rule generation system 106, an authentication computer 116, and an authorization computer 110. Each of these systems and computers can communicate operably with each other via any suitable communication protocol over any suitable communication medium, including the Internet.

[0056] For simplicity of illustration, Figure 1 a certain number of components are shown in [reference]. However, it should be understood that embodiments can include more than one of each component. Additionally, some embodiments can include fewer or more components than all of the components shown in [reference]. Figure 1

[0057] The user computing device 102 can be in any suitable form. For example, suitable user computing devices can be handheld and compact so that they can fit into a user's pocket. Examples of the user computing device 102 can include any device capable of accessing the Internet. Specific examples of the user computing device 102 include cellular phones or wireless phones (e.g., smart phones), tablet phones, tablet computers, laptop computers, desktop computers, personal digital assistants (PDAs), pagers, portable computers, smart cards, etc.

[0058] The user computing device 102 can accept input from the user that includes access data associated with the user's attempt to access a resource. As a non - limiting example, the resource can be a physical resource (e.g., a building or a lockbox) or an electronic resource (e.g., a local computer account, a digital file or document, a network database, an email inbox, a payment account, or a website login). For example, the access data can include one or more of a username, an account number, a token, a password, a personal identification number, a signature, and / or a digital certificate. The user computing device 102 can transmit the access data, either fully or partially, to the access device 108. Alternatively or additionally, the user computing device 102 can transmit the access data to the server computer 104.

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

[0060] The access device 108 and / or the user computing device 102 may include a user input interface, such as a keypad, a keyboard, a fingerprint reader, a retina scanner, any other type of biometric reader, a magnetic stripe reader, a chip card reader, a radio frequency identification reader, or a wireless or contactless communication interface, etc.

[0061] In one example, a user may input one or more of an account number, a personal identification number, and / or a password into the access device 108 to request access to a physical resource (e.g., to open a locked secure door to enter a building). The access device 108 or a separate computer operably connected to the access device 108 may generate and send an access request to the server computer 104 to request access to the resource.

[0062] In another example, a user may operate the user computing device 102 to request access to an electronic resource (e.g., a website or a file). Such a request may be transmitted from the user computing device 102 to the access device 108, which may forward the request to the server computer 104. The request may be transmitted wirelessly and may be encrypted. The request may be sent in response to user input at a screen or a voice command, or initiated by a gesture, such as by tapping a phone to a terminal.

[0063] The access rule generation system 106 may generate an access rule 104H for the server computer 104 based on the access data. The access rule generation system may determine the access rule based on historical data regarding previous access requests, statistical models, and / or machine learning algorithms. The server computer 104 may define and / or provide guidelines for the rules to be evaluated by the access rule generation system 106. The method of generating access rules is described in detail in U.S. Patent No. 9,853,993B1, "Systems and Methods for Generation and Selection of Access Rules", which is hereby incorporated herein by reference in its entirety.

[0064] The authentication computer 116 may be configured to verify (or authenticate) the user and / or the account associated with the user. Below with respect toFigure 2B Describe the authentication computer 116 in more detail.

[0065] The authorization computer 110 can control access to resources (such as physical or electronic resources). The authorization computer 110 can be associated with, for example, a secure website and maintain a database of access data suitable for granting access to the website. As another example, the authorization computer 110 can be associated with an issuer (such as a bank) that issues and maintains user accounts for users and determines whether a user has sufficient funds to complete a transaction. Alternatively, the authorization computer 110 can be a service provider different from the resource provider. The authorization computer 110 can include a processor and a computer-readable medium coupled to the processor, the computer-readable medium including code that can be executed by the processor to perform the functions described herein.

[0066] The authorization computer 110 can include the function of receiving an authorization request message. Subsequently, based on the authentication data and / or other information received from the server computer 104, such as an access indicator, the authorization computer 110 can grant or deny access to the resource, as described below with respect to Figure 2A Describe.

[0067] Some entities can perform the functions of both the authorization computer 110 and the authentication computer 116 (such as a resource provider system that controls access to one or more resources). Embodiments cover such single-entity computers that can perform one or more of the functions described herein.

[0068] B. Server Computer

[0069] In some embodiments, the server computer 104 can be configured to manage and evaluate access requests. As Figure 2A Depicted in, the server computer 104 can include a network interface 104A, a processor 104B, a memory 104C, and a computer-readable medium 104D coupled to the processor 104B. The computer-readable medium 104D can include code that can be executed by the processor 104B to perform the functions described herein. The server computer 104 can also include or be communicatively coupled to a rules database 104G.

[0070] The rules database 104G can be a storage unit and / or device for storing data (such as a file system, a database, a collection of tables, or other storage mechanisms). The rules database 104G can include multiple different storage units and / or devices. The rules database 104G can store one or more access rules 104H. The access rules 104H can specify criteria for identifying fraudulent access requests. Each access rule 104H can include one or more conditions corresponding to one or more parameters of the access request.

[0071] The network interface 104A can be configured to connect to one or more communication networks to allow the server computer 104 to communicate with other entities such as an authentication computer 116, an authorization computer 110, an access rule generation system 106, etc.

[0072] The processor 104B can be implemented as one or more integrated circuits (e.g., one or more single-core or multi-core microprocessors and / or microcontrollers). The processor 104B can be used to control the operation of the server computer 104. The processor 104B can execute various programs in response to program code or computer-readable code stored in the memory 104C. The processor 104B can include the function of maintaining multiple simultaneously-executing programs or processes.

[0073] The memory 104C can be implemented using any combination of any number of non-volatile memories (e.g., flash memory) and volatile memories (e.g., DRAM, SRAM), or any other non-transitory storage medium or combination of media.

[0074] The computer-readable medium 104D can include one or more non-transitory media for storage and / or transmission. As an example, suitable media include random access memory (RAM), read-only memory (ROM), magnetic media such as a hard disk drive or a floppy disk, or optical media such as a compact disc (CD) or a digital versatile disc (DVD), flash memory, etc. The computer-readable medium 104D can be any combination of such storage or transmission devices.

[0075] The computer-readable medium 104D can include software code stored as a series of instructions or commands. The computer-readable medium 104D can include an access request analyzer module 104E, a messaging module 104F, an exemption module 104I, and a post-authorization module 104J.

[0076] The access request analyzer module 104E can include code for determining an access score based on access rules applied to access data, authentication data, and / or access data. The access score can correspond to the likelihood that the access request is fraudulent. For example, the access score can be a numerical value from 0 (almost certainly not fraudulent) to 10 (almost certainly fraudulent). As in the case of the previous example, the access score can increase proportionally with the risk level of the access request. Alternatively, the access score can change inversely with the risk level of the access request (e.g., an access score of 100 corresponds to the most trusted access request, while an access score of 0 corresponds to the most risky access request). If the access score indicates that the access request is likely to be fraudulent, the server computer 104 can reject the access request and / or recommend to another entity (e.g., the authorization computer 110) to reject the access request.

[0077] The access request analyzer module 104E may also be configured to generate an access indicator, in whole or in part, based on an access score. The access indicator may be a flag to be inserted into a message. The access indicator may indicate whether the server computer approves a request to access a resource. The access indicator may also indicate a guarantee of the access request made by an entity associated with the server computer 104. For example, a merchant or building security company that manages the server computer 104 may guarantee the decisions made by the server computer 104. The guarantee may be a financial guarantee and / or indemnification for any losses incurred as a result of access fraudulently obtained.

[0078] The access request analyzer module 104E may also be configured to identify one of a plurality of profiles corresponding to an access request. The access request analyzer module 104E may use a stored mapping to accomplish this. For example, access data such as transaction amount, location, and / or time of day may be mapped to a profile. The profile may be risk-related. For example, a payment transaction with a higher value may be associated with a higher risk level and may therefore require increased scrutiny.

[0079] The messaging module 104F may include code for preparing and transmitting messages. The messaging module 104F may also be configured to receive and analyze messages (e.g., authentication response messages). The messaging module 104F may include functionality for generating authentication request messages and authorization request messages. The messaging module 104F may be configured to prepare messages to contain information generated by the access request analyzer module and / or received in an authentication response message, such as authentication data, access scores, access indicators, etc. The messaging module 104F may include functionality for transmitting authentication request messages and authorization request messages.

[0080] The exemption module 104I may include code for determining whether to apply an exemption. An exemption may be applied so that the system skips the authentication operation or performs a limited authentication operation. The exemption may be applied based on configurable rules. For example, the exemption may apply to transactions below a threshold amount, white lists, risk-based rules, and / or the like.

[0081] The post-authorization module 104J may include code for evaluating an access request after authorization. In some cases, although the authorization computer has approved access to a resource, the post-authorization module 104J may decide to deny the access request. For example, the authorization operation may reveal that certain credentials are invalid, in which case the post-authorization module 104J may decide after authorization that the access request should be denied.

[0082] The access request analyzer module 104E can be communicatively coupled to the access rule generation system 106, which determines access rules as described above. The access request analyzer module 104E can include an application programming interface (API) for communicating rule guidelines to the rule generation system.

[0083] C. Authentication Computer

[0084] In some embodiments, the authentication computer 116 can be configured to authenticate a user making an access request. As Figure 2B depicted, the authentication computer 116 can include a network interface 116A, a processor 116B, a memory 116C, and a computer-readable medium 116D coupled to the processor 116B. The computer-readable medium 116D can include code that can be executed by the processor 116B to perform the functions described herein.

[0085] The network interface 116A can be configured to connect to one or more communication networks to allow the authentication computer 116 to communicate with other entities such as, for example, the server computer 104, the user computing device 102, the access device 108, etc.

[0086] The processor 116B can be substantially similar to the processor 104B described above with respect to Figure 2A The memory 116C can be substantially similar to the memory 104C described above with respect to Figure 2A

[0087] The computer-readable medium 116D can include one or more non-transitory media for storage and / or transmission. By way of example, suitable media include random access memory (RAM), read-only memory (ROM), magnetic media such as a hard disk drive or a floppy disk, or optical media such as a compact disc (CD) or a digital versatile disc (DVD), flash memory, etc. The computer-readable medium 116D can be any combination of such storage or transmission devices.

[0088] The computer-readable medium 116D can include software code stored as a series of instructions or commands. The computer-readable medium 116D can include an enrollment module 116E, a verification module 116F, and a messaging module 116G.

[0089] The enrollment module 116E can include code for determining the enrollment status of one or more service parties associated with an enhanced authentication protocol. The enrollment status can be determined based on an identifier received in an authorization request message. For example, the enrollment status of an issuer can be determined based on a bank identification number (BIN). The enrollment module 116E can access a stored mapping of BINs to entities enrolled in the authentication system.

[0090] ​The verification module 116F may include functions for authenticating a user and / or an account. The verification module 116F may authenticate a user based on data received in an authentication request message, such as access data. In some embodiments, the access data may be provided by the user computing device 102, the access device 108, and / or the server computer 104. For example, the access data may include one or more of the following: the time at which the access request was received, the date at which the access request was received, the source location of the access request, the amount of resources requested, the identifier of the requested resources, the identifier of the user, the access device 108, and / or the user computing device 102, the location of the user, the access device 108, and / or the user computing device 102, an indication of the purpose for which the resources were requested, and / or an indication of the type, status, amount, or form of the requested resources. Alternatively or additionally, the verification module 116F may generate access data based on the received information. For example, the verification module 116F may calculate a new value based on a set of timestamps retrieved from the access device 108. The verification module 116F may verify the access data based on information stored at the authentication computer 116 and / or the server computer 104.

[0091] The verification module 116F may generate authentication data. The authentication data may indicate the authentication result (e.g., whether the user has been authenticated). The authentication data may also include detailed information generated during the authentication process, such as an authentication code, an authentication password, and / or supplementary data, as described below.

[0092] The authentication data may include an authentication code. The authentication code may be a numerical value indicating the authentication result. For example, in a financial transaction, an electronic commerce indicator (ECI) code is used to indicate whether a user has been authenticated. As a specific example, an ECI value of 5 may indicate that the user has been authenticated. An ECI value of 01 may indicate that authentication cannot be completed. Alternatively or additionally, the ECI code may be a word or letter (e.g., "A" or "Auth" indicates authenticated; "N" or "Rejected" indicates not authenticated, etc.).

[0093] The authentication data may also include an authentication password. The authentication password may be a password used to verify the integrity of the access data. The authentication password may be a unique value for the access request. As a non-limiting example, the authentication password may be a cardholder authentication verification value (CAVV) or an account holder authentication value (AAV).

[0094] The authentication data may also include detailed information ("supplementary data") generated and / or analyzed by the authentication computer 116 during the authentication process. For example, the supplementary data may include token-based authentication data, biometric authentication data, data corresponding to previous user behavior (e.g., access attempts or locations associated with the user), etc.

[0095] The message transceiver module 116G may include the function of receiving an authentication request message from the server computer 104 and transmitting an authentication response message to the server computer 104.

[0096] II. Pre - authorization access request screening

[0097] Figures 3 to 7 Several variants of the pre - authorization access request screening method are shown. In each case, the system uses pre - authorization access request screening to transmit information to an authorization computer. The authorization computer can then use the received information to determine whether to approve or deny access to the resource. The pre - authorization access request screening may include an authentication operation to generate authentication data, as described with respect to Figures 3 to 5 Alternatively or additionally, the system pre - authorization access request screening may include a fraud check for generating an access indicator that provides a simple indication of whether the access request should be approved or denied, as described with respect to Figures 6 to 7 described.

[0098] A. Using an authentication code and an authentication password

[0099] Figure 3 An example operation set 300 for pre - authorization access request screening using an authentication code and an authentication password is shown. The operation can be initiated by a user requesting access to a resource through a user computing device and / or an access device. The operation can be executed by a server computer 310 (which can be substantially similar to Figure 1 the server computer 104 of FIG. 2), an authentication computer 312 (which can be substantially similar to Figure 1 and 3 the authentication computer 116 of FIG. 2) and an authorization computer 314 (which can be substantially similar to Figure 1 the authorization computer 110 of FIG. 2).

[0100] In step S301, the server computer 310 transmits an authentication request message to the authentication computer 312. The authentication request message may include access data received from the user or the user device.

[0101] In step S302, the authentication computer 312 performs an authentication operation. The authentication computer 312 may perform an operation to verify the user based on the access data received in the authentication request message. The authentication computer may analyze the access data.

[0102] The authentication operation may include determining a risk level associated with the user and / or the access request. Based on the risk level, the authentication computer 116 may determine whether the user should be authenticated.

[0103] The authentication operation may include escalating authentication. For escalating authentication, the authentication computer 312 may request additional data from the user directly or through the server computer 310. For example, the authentication computer 312 may transmit a message to the user computing device (e.g., Figure 1 the user computing device 102) of Figure 1 such that the user computing device presents a modality for the user to input a password. The authentication computer 312 may then receive the password for authenticating the user. As another example, the authentication computer may transmit an escalation request to the server computer 310. The server computer 310 may then forward the escalation request to the access device (e.g.,

[0104] the access device 108) of

[0105] such that the access device prompts the user to input a personal identification number (PIN). Alternatively, the authentication computer 312 may perform a risk-based authentication operation without challenging the user for additional information. Figure 1 The authentication computer 312 may derive an authentication result (e.g., whether the user has been authenticated). The authentication computer 312 may generate authentication data to be transmitted back to the server computer in an authentication response, and the authentication data may include and / or support the authentication result.

[0106] The authentication data generated by the authentication computer 312 may include an authentication code. As described above with respect to Figure 1 the authentication code may be an alphanumeric code indicating the authentication result. As a non-limiting example, if the access request includes a payment request, the authentication code may be an ECI code.

[0107] The authentication data generated by the authentication computer 312 may also include an authentication password. As described above with respect to

[0108] the authentication password may be a password such as a CAVV or AAV. The authentication password may be a unique identifier for the access request. The authentication password may indicate that this particular access request has been authenticated.

[0109] The authentication computer 312 may prepare an authentication response message including the authentication code and the authentication password. The authentication computer 312 may, for example, generate an Extensible Markup Language (XML) message for transmission to the server computer.

[0110] In step S304, the server computer 310 transmits an authorization request to the authorization computer 314. The authorization request may include an authentication result, which may include an authentication code and / or an authentication password (e.g., ECI and / or CAVV).

[0111] In step S306, the authorization computer 314 performs an operation of risk assessment. The authorization computer 314 may base the risk assessment on the information received in the authorization request message. For example, the authorization computer 314 may use the ECI code value to determine whether to approve or reject the resource access request.

[0112] In step S308, the authorization computer 314 transmits an authorization result to the server computer 310. The authorization computer 314 may transmit the authorization result in an authorization response message. The authorization result may include an instruction to approve or reject the access request.

[0113] B. Relating the authentication code to risk

[0114] Figure 4 An example operation set 400 for pre - authorization access request screening is shown, where the authentication code is related to risk. The operations may be performed by a server computer 410 (which may be substantially similar to Figures 1 to 2A the server computer 104), an authentication computer 412 (which may be substantially similar to Figure 1 and 2B the authentication computer 116) and an authorization computer 414 (which may be substantially similar to Figure 1 the authorization computer 110).

[0115] In step S401, the server computer 410 transmits an authentication request message to the authentication computer 412, such as described above with respect to Figure 4 that.

[0116] In step S402, the authentication computer 412 may perform an authentication operation. The authentication operation may be performed substantially as described above with respect to Figure 4 that. Additionally, the authentication computer 412 may re - assign the authentication code to correspond to the determined risk level. For example, the authentication computer 412 may set the authentication code to 5 for low - risk transactions and to 1 for high - risk transactions. The authentication computer may generate a mapping between the existing authentication code and the risk. Thus, in some embodiments, the authentication computer may determine an authentication level. The authentication computer may provide the mapping to the authorization computer.

[0117] In step S403, the authentication computer 412 transmits an authentication response message including authentication data to the server computer 410. The transmission of the authentication response message may be substantially as described above with respect to Figure 4be performed as described. Additionally, the authentication response message may include an authentication code assigned based on a risk level.

[0118] In step S404, the server computer 410 transmits an authorization request to the authorization computer 414, as described above with respect to Figure 4 be performed as described. Additionally, the authorization response message may include an authentication code assigned based on a risk level.

[0119] In step S406, the authorization computer 414 performs an operation to determine whether to authorize the access request. The authorization operation may include the authorization computer's own risk assessment. The risk assessment may include using the received authentication code corresponding to the risk level. This may reduce the amount of risk analysis done on the part of the authorization computer 414.

[0120] In step S408, the authorization computer 414 transmits the authorization result to the server computer 410. The authorization result may include an instruction to approve or deny the access request.

[0121] C. Passing Supplementary Data Using Data Fields

[0122] In addition to or instead of the authentication code and / or authentication password, the system may pass more detailed data (e.g., supplementary data, as described above with respect to Figure 2B be performed as described) to the authorization computer. The supplementary data may be passed in a dedicated data field of the authorization request message, as detailed below.

[0123] Figure 5 An example operation set 500 for pre-authorization access request screening is shown, where supplementary data is passed in a specific field of the authorization request message. The operations may be performed by a server computer 510 (which may be substantially similar to Figure 1 the server computer 104 of FIG. 2), an authentication computer 512 (which may be substantially similar to Figure 1 and 3 the authentication computer 116 of FIG. 2) and an authorization computer 514 (which may be substantially similar to Figure 1 the authorization computer 110 of FIG. 2).

[0124] In step S501, the server computer 510 transmits an authentication request message to the authentication computer 512, as described above with respect to Figure 4 be performed as described.

[0125] In step S502, the authentication computer 512 may perform an authentication operation. The authentication computer 512 may perform the authentication operation substantially as described above with respect to Figure 4 FIG. 2 and / or FIG. 5. The authentication computer 512 may also generate supplementary data. As described above with respect to Figure 1As described, the supplementary data may include various types of data generated and / or processed by the authentication computer, such as risk-based authentication data, biometric data, customer data, device data, order data, etc.

[0126] In step S503, the authentication computer 512 transmits an authentication response message including authentication data to the server computer 510. The transmission of the authentication response message may be performed substantially as described above with respect to Figure 2B In addition, the authentication response message includes supplementary data (e.g., detailed information, biometric data, etc. generated during the authentication process). The supplementary data may be provided together with other authentication data such as an authentication password and / or an authentication code.

[0127] In step S504, the server computer 510 transmits an authorization request message to the authorization computer 514, as described above with respect to Figure 4 The supplementary data may be seamlessly transmitted in a data field. The authorization request message may be formatted according to various standards (e.g., International Organization for Standardization (ISO) 8583 and 20022 are commonly used for financial messaging; some service providers use their own formats). These formats may assign data fields to discrete data elements (e.g., for a given standard, the transaction ID may be in field 1, the amount may be in field 10, etc.). Some fields are of fixed length (e.g., fixed character length). Some fields have variable length (e.g., up to a certain number of bits). Some fields may be "open data fields" that are independent of a specific data set or size. For example, depending on the processing system, fields such as field 34 and 48 may remain open. By utilizing open data fields such as field 34 of the authorization request message, the authorization request message may be overloaded with new types of information.

[0128] In step S506, the authorization computer 514 performs an operation to determine whether to approve or reject the access request. The authorization computer 514 may make the determination substantially as described above with respect to Figure 3 and / or 4. In addition, the evaluation may include utilizing the supplementary data received in the data fields of the authorization request. For example, the authorization computer 514 may receive supplementary data indicating that the authentication computer 512 has verified the user's biometric data. The authorization computer may rank the biometric verification higher than other types of verification performed by the authentication computer (e.g., password data). Thus, the authorization computer 514 may approve the access request fully or partially based on receiving the biometric verification indication.

[0129] In step S508, the authorization computer 110 transmits the authorization result to the server computer 104. The authorization result specifies whether the access request is approved or rejected.

[0130] III. Adding an Access Indicator to a Data Field

[0131] Figures 6 to 7 Shows an additional variant of the pre - authorization access request screening method. Similar to the method described above with respect to Figures 3 to 5 The authentication data generated by the authentication computer is used to transmit information to the authorization computer. As Figures 6 to 7 shown, the system can use the data generated in the fraud check to generate an access indicator that provides a simple indication of whether the access request should be approved or rejected.

[0132] A. Access Indicator

[0133] Figure 6 Shows an example operation set 600 for pre - authorization access request screening for passing an access indicator using a data field. The operations can be performed by a server computer 610 (which can be substantially similar to Figures 1 to 2A server computer 104), an authentication computer 612 (which can be substantially similar to Figure 1 and 2B authentication computer 116) and an authorization computer 614 (which can be substantially similar to Figure 1 authorization computer 110).

[0134] In step S601, the server computer 610 transmits an authentication request message to the authentication computer 612, as described above with respect to Figure 4 described.

[0135] In step S602, the authentication computer 612 can perform authentication operations. The authentication computer can perform authentication operations substantially as described above with respect to Figure 3 , 4 and / or 5.

[0136] In step S603, the authentication computer 116 transmits an authentication response message including authentication data to the server computer 610. The transmission of the authenticated authentication response message can be performed substantially as described above with respect to Figure 3 , 4 and / or 5.

[0137] The server computer 610 can evaluate the likelihood that the access request is fraudulent. The server computer 610 can use an access rule generation system (similar to Figure 1 access rule generation system 106) to retrieve and / or generate access rules for evaluating the access request. The server computer 610 can also use access data to evaluate the access request. Alternatively or additionally, the server computer 610 can evaluate the access request based on the authentication data. The server computer 610 can generate an access score indicating the risk level associated with the access request.

[0138] Based on the access score, the server computer 610 may generate an access indicator. The access indicator may indicate that the server computer has approved the access request. The access indicator may be an alphanumeric value. For example, the access indicator may be the letter "A" inserted into the authorization request message to indicate that the server computer 610 has approved the access request. Alternatively or additionally, the server computer 610 may use different access indicators to further qualify the fraud screening result. For example, the server computer may generate an "A" access indicator for an approved access request and an "R" access indicator for an access request that has been screened but requires additional review by the server computer 610. The server computer 610 may avoid generating an access indicator for an access request that has not been assigned an appropriately high access score. The access indicator may represent the result of the server computer using the access rules generated by the access rule generation system.

[0139] In some embodiments, the server computer 610 is able to accurately evaluate the risk level of an access request using data elements that are not available to the authorization computer 614. Data elements that are available to the server computer 610 but not to the authorization computer 614 may include: background data (e.g., device fingerprint, IP address, etc.), access device data (e.g., positive list, stock keeping unit (SKU) level information, etc.), and / or calculated data (e.g., risk score, velocity, relevance, etc.). These data elements may be utilized to provide an appropriate access indicator to the authorization computer 614.

[0140] In step S604, the server computer 610 transmits the authorization request message to the authorization computer 614, as described with respect to Figures 3 to 5 Additionally, the server computer 610 includes the access indicator in the outbound authorization request message. The server computer 610 may add the access indicator to the authorization request message (e.g., add it in field 34 of the authorization request message or other suitable data field).

[0141] In some embodiments, the authorization request message may also include any additional authentication data described above with respect to Figures 3 to 5 For example, authentication codes, authentication passwords, supplementary data, etc. Alternatively, the server computer 610 may include only the access indicator without additional risk data to simplify the analysis required by the authorization computer 614.

[0142] In step S606, after receiving the authorization request message, the authorization computer 614 performs the operations described above with respect to Figures 3 to 5The described authorization operation. Alternatively or additionally, the authorization computer 614 may base the authorization decision, in whole or in part, on the received access indicator. The authorization computer 614 may approve or deny the access request based solely on the access indicator. The authorization computer 614 may determine the extent to which it relies on the access indicator to generate the authorization result.

[0143] In step S608, the authorization computer 614 transmits the authorization result to the server computer 610. The authorization result may include an instruction to approve or deny the access request.

[0144] B. Securing an access request

[0145] Figure 7 An example set of operations 700 for pre-authorization access request screening is shown, including securing an authenticated access request. The operations may be performed by a server computer 710 (which may be substantially similar to Figures 1 to 2A server computer 104), an authentication computer 712 (which may be substantially similar to Figure 1 and 2B authentication computer 116) and an authorization computer 714 (which may be substantially similar to Figure 1 authorization computer 110).

[0146] Operations 701 to 704 may be performed substantially as described above with respect to Figure 6 operations 602 to 604. Additionally, the system may generate an access indicator to represent the securing. The access indicator representing the securing may take a different form from the access indicator representing the screening result described above with respect to Figure 6 For example, the server computer 710 may assign the access indicator "A" to an authorized access request and the access indicator "G" to a secured access request. As another example, the server computer 710 may use two access indicators for a secured transaction (e.g., both the A and G flags may be inserted into the authorization request message to indicate a secured access request).

[0147] The server computer 710 may construct a securing model around the access indicator. If the access indicator is present in the authorization request message, the access indicator may indicate that an entity associated with the server computer (e.g., a security company or a merchant) secures the access request. Thus, if the access request is fraudulent, the access indicator may indicate a shift in liability. The access indicator representing the securing may be used in conjunction with a pre-existing agreement between the server computer 710, the authentication computer 712, and / or the authorization computer 714.

[0148] IV. Method for pre-authorization access request screening

[0149] Figures 10 to 13Shows various methods for performing pre - authorization access request screening and passing the results to an authorization computer to determine whether to grant access to a resource.

[0150] A. Using an access indicator

[0151] With respect to Figure 8 Describes a method for pre - authorization access request screening. As described above with respect to Figures 3 to 7 The server computer can transmit an authorization request message including an access indicator and / or authentication data to an authorization computer to determine whether to approve or deny a resource access request. Figure 8 The flowchart of shows the operations for generating and processing such messages. Figure 8 The operations shown in can be performed by Figure 1 and 2A The server computer 104 and the authorization computer 110 shown in .

[0152] Before step 802, a user can request a user device to access a resource. For example, the user can try to enter a building by tagging a card (user device) to an access device. As another example, the user can try to purchase clothing online by entering payment information into a resource provider website through a user computing device such as a mobile phone. In either case, the user can submit access data (e.g., employee identification data, payment data, user name, etc.) to the access device or the user computing device. Then, the access device and / or the user computing device transmits a resource access request including the access data to the server computer.

[0153] In step 802, the server computer receives a request from a requesting device for a user device to access a resource. The requesting device can be a user computing device or an access device. The request includes access data. The request can be received, for example, by a message and / or a push to an open API of the server computer.

[0154] After step 802, the server computer can transmit and receive an authentication request message, as described below with respect to Figure 9 Or, the server computer can continue to step 804 without transmitting and receiving an authentication request message. Figures 10 to 13 Shows situations where authentication may or may not be performed based on an exemption application.

[0155] In step 804, the server computer determines an access score based on the access data. The server computer can use access rules retrieved from an access rule generation system to determine the access score. The access rule generation system can determine access rules based on historical data regarding previous access attempts, statistical models, and / or machine learning algorithms. The server computer can fine - tune the modeling to customize the access rules. The server computer can also use the access data and / or authentication data to determine the access score.

[0156] The server computer may apply selected access rules to access data, resource access parameters, and / or authentication data. For example, the rule is "if country = Brazil and amount > $10,000, then reject, otherwise approve." If the country is Brazil and the amount is $9,000, the rule result is approve. If the country is Brazil and the amount is $11,000, the rule result is reject. If the amount is $16,000 and the country is Sweden, the rule result is approve.

[0157] The server computer may generate an access score based on a comparison of the rule values with the access data values. Continuing with the example in the previous text where the rule specifies country and dollar amount, the higher the dollar amount, the higher the access score may be. A $20,000 transaction in Brazil may have an access score of 4, while a $10,001 transaction in Brazil may have an access score of 3. Compared to a situation where only one factor complies with the rule, the access score may increase if both the country and the dollar amount comply with the rule (e.g., $10,001 in Brazil has an access score of 3, while $9,500 in Brazil has an access score of 2).

[0158] In step 806, the server computer compares the access score with a threshold. The threshold may represent the access score that should correspond to an authorized access request. Alternatively or in addition, the server computer may use multiple thresholds corresponding to multiple respective results. For example, if the access score is 95 or higher, the server computer can guarantee the transaction; if the access score is between 85 and 95, the server computer authorizes the access request; if the access score is between 75 and 95, the server computer marks the access request for manual review.

[0159] In step 808, the server computer generates an access indicator based on the access score. The server computer may generate the access indicator after determining that the access score reaches or exceeds the threshold. As described above with respect to Figures 6 to 7 The access indicator may take different forms to fine-tune the information passed to the authorization computer. The different forms may, for example, correspond to one of several thresholds. Alternatively, the server computer may use a single flag corresponding to a single threshold.

[0160] The server computer can generate an access indicator by comparing the access score with a threshold. For example, the server computer can determine that if the access score reaches or exceeds the threshold, the access request has passed the access screening. As a specific example, the server computer calculates an access score of 80 for a particular access request. The server computer identifies the stored threshold of 78 as indicating that the access screening has been passed. Based on comparing the access score with the threshold, the server computer determines that the access request has passed the screening and should be approved. On the other hand, if the value is less than the threshold (e.g., 77 or less), the server computer can determine that the access request has not passed the access screening.

[0161] Alternatively or additionally, the server computer can generate an access indicator by comparing the access score with multiple thresholds. For example, the server computer can use a first threshold (e.g., 78, for determining that the access request should be approved). The server computer can also use a second threshold (e.g., 49) for determining that access to the resource should be denied. The second threshold can correspond to a second flag, warning message, etc. For access requests that exceed the second threshold but do not meet the criteria for exceeding the first threshold (e.g., 50 to 77), the server computer can refrain from generating an access indicator. As another example, the server computer can use the first threshold for access requests that are very likely to be valid (e.g., access score > 95) and the second threshold for access requests with a satisfactory likelihood of validity (e.g., access score > 75).

[0162] Based on whether the access request passes the access screening, the server computer may or may not generate an access indicator indicating that access to the resource should be granted. Thus, the access indicator can be used to ensure that the access request has passed the server computer's access screening process. This can indicate that the server computer has determined that the access request is unlikely to be fraudulent.

[0163] In some embodiments, the access indicator can represent a guarantee. The access indicator can indicate that the entity managing the server computer (e.g., a merchant, security company, etc., that facilitates access to the resource) guarantees the access request. Alternatively or additionally, the guarantee can be made by a third-party service provider that performs fraud checks on behalf of the server computer. If the access request turns out to be fraudulent, the entity managing the service provider or the service provider performing the fraud check will assume any liability associated with the unauthorized access.

[0164] In step 810, the server computer prepares an authorization request message that includes the access indicator. The server computer can place the access indicator in a specific field (e.g., field 34) of the authorization request message. Alternatively or additionally, the server computer can include the access score in the authorization request message. The server computer transmits the authorization response message to the authorization computer.

[0165] In step 812, the server computer transmits an authorization request message including an access indicator to the authorization computer. The server computer may, for example, transmit an XML message to the authorization computer, and / or push the message to an open API of the authorization computer.

[0166] In step 814, the authorization computer approves or denies access to the resource by the user device based on the access indicator. In some embodiments, the authorization computer may trust the access indicator / server computer sufficiently to simply approve or deny the access request based solely on the access indicator (e.g., if the access indicator is present in the message, the access request will be approved, but if the access indicator is not present in the message, the access request will be denied). The authorization computer may be particularly confident in relying on the access indicator if the access indicator indicates a guarantee made by the server computer. Alternatively, the authorization computer may use the access indicator as a supplement to its access determination process. For example, the authorization computer approves or denies the access request based on a calculated score from one to one hundred, and the presence of the access indicator increases the score by ten points.

[0167] If the server computer determines in step 806 that the access score does not meet or exceed the threshold, the server computer may avoid generating an access indicator.

[0168] In step 816, the server computer may prepare an authorization request message without including an access indicator. In the case where the access score does not meet or exceed the threshold, the server computer may prepare a standard authorization request message. Alternatively or additionally, the server computer may include information indicating that the access request should be denied.

[0169] In step 818, the server computer may transmit the authorization request message to the authorization computer. The server computer may, for example, transmit an XML message to the authorization computer, and / or push the message to an open API of the authorization computer.

[0170] In step 820, the authorization computer may approve or deny access to the resource. The authorization computer may perform its own risk check to approve or deny access to the resource without using the access indicator. The authorization computer may use other information received from the server computer (e.g., access score, authentication data, etc.) to inform its decision. If the access indicator is not present in the authorization request, the authorization computer is more likely to deny access to the resource. The authorization computer may, for example, determine that an authorization request without an access indicator should always be denied. Alternatively, the authorization computer may determine that an authorization request without an access indicator should be subject to more scrutiny.

[0171] B. Using Authentication Data

[0172] Relative to Figure 9Describes a method for screening pre-authorization access requests using authentication data. Figure 9 The operations shown in Figures 1 to 2B can be performed by the server computer 104, authentication computer 116, and authorization computer 110 shown in

[0173] In step 902, the server computer receives a request from a requesting device for a user device to access a resource, the request including access data. Step 902 can be substantially similar to step 802 described above with respect to Figure 8 as described.

[0174] In step 904, the server computer generates an authentication request message. The server computer can generate the authentication request message using a format acceptable to the authentication computer. The authentication request message can include, in whole or in part, the received access data and / or information such as access data in whole or in part. The access request can also include an access request indicator (e.g., a series of numbers and / or letters identifying the access request). The server computer transmits the authentication request message to the authentication computer.

[0175] In step 906, the authentication computer generates an authentication response message, the authentication response message including authentication data corresponding to the authentication of the user device. The authentication computer can determine whether to authenticate the user based on information (e.g., access data) extracted from the authentication request message. The authentication computer can generate authentication data including an authentication code such as an ECI code. The authentication data can also include an authentication password such as a CAVV. Other details regarding such codes and values are described above, for example, with respect to Figure 1 and 3 as described.

[0176] In some embodiments, the authentication computer can perform risk-based authentication. The authentication data generated by the authentication computer can include supplementary data associated with the risk-based authentication. The authentication computer can transmit via an authentication code or authentication password (e.g., by assigning an ECI based on a determined risk level).

[0177] The authentication computer transmits the authentication response message including the authentication data to the server computer. The authentication computer can transmit the authentication response message, for example, via wired or wireless communication and / or a push to an API.

[0178] In step 908, the server computer receives the authentication response message including the authentication data from the authentication computer. The server computer can receive the response, for example, via a messaging bus or a push to an API open to the server computer.

[0179] In step 910, the server computer determines an access score based on at least a subset of the authentication data and the access data. As described above with respect to Figure 8A method for determining an access score based on access data is described in detail. The server computer may also use authentication data to determine the access score. For example, access rules may take into account authentication data such as risk-based authentication results, whether the user has been authenticated, etc. As a specific example, the server computer may receive authentication data from an authentication computer, the authentication data including historical access data associated with the user. The server computer may increment or decrement the access score based on a comparison of the historical transaction data with the access data corresponding to the current access request.

[0180] In step 912, the server computer determines whether to transmit an authorization request message to the authorization computer based on the access score. The server computer may compare the access score with one or more thresholds when determining whether to transmit an authorization request message to the authorization computer. For example, if the access score is below a first threshold, the server computer may avoid transmitting the authorization request message because access to the resource should not be granted. If the access score is above the first threshold, the server computer may transmit an authorization request message including an access indicator or other information, as described above with respect to Figures 3 to 8 If the access score is above a second threshold, the server computer may also provide a guarantee for the access request.

[0181] After step 912, the server computer may prepare the authorization request message. The authorization request message may include the access score and / or related data such as an access indicator, ECI, and / or similar data, as described above with respect to Figures 3 to 8 described in detail.

[0182] The authorization computer may approve or deny access to the resource directly or indirectly based on the access score, as described above with respect to Figures 3 to 8 described in detail.

[0183] C. Applying an exemption to skip authentication

[0184] With respect to Figure 10 A method for screening pre-authorization access requests using authentication exemptions is described. Figure 10 The operations shown in Figures 1 to 2B may be performed by the server computer 104, the authentication computer 116, and the authorization computer 110 shown in

[0185] In step 1002, the messaging module 104F makes a call to the access request analyzer module 104E. The messaging module 104F may transmit information such as access data to the access request analyzer module 104E.

[0186] The access request analyzer module 104E can select a profile for the access request. The access request analyzer module 104E can assign the access request to a predefined profile based on access data. For example, a purchase over $10,000 can correspond to a first profile, a purchase below $100 can correspond to a second profile, and a purchase between $100 and $10,000 can correspond to a third profile. As other examples, the profiles can correspond to location, characteristics of the resource access requester, time of day, and / or the like.

[0187] In step 1004, the access request analyzer module 104E can send information about the selected profile to the exemption module 104I. Alternatively or additionally, the access request analyzer module 104E can send the access data to the exemption module 104I. The exemption module 104I can determine whether to apply an exemption based on the selected profile and / or the access data. For example, an exemption can apply to an access request for a profile corresponding to a trusted user or a profile for a purchase below $100. As another example, an exemption can apply to an access request corresponding to Payment Services Directive 2 (PSD2). The PSD2 exemption is an exemption from the requirement that all payment transactions in the European Union should go through a high-level authentication process. The PSD2 exemption includes Transaction Risk Analysis (TRA), where: the number of refunds is below a certain level; Whitelist (WL), which applies when the trusted resource provider is already on the whitelist; One Leg Out (OLO), which applies when one of the parties to the transaction is not located in the EU; or Low Value (LV), where the transaction amount is less than 30 euros. The exemption module 104I can determine that one or more such exemptions apply based on the profile corresponding to the access request and / or the access data.

[0188] In step 1006, optionally, the system can reject the access request after selecting the profile. The access request can be rejected based on access rules and the received access data after selecting the profile, for example, before authentication or authorization. For example, the system can reject an access request for an individual or country on a blacklist. If the authorization request is rejected, the system can avoid continuing to process the request.

[0189] In step 1008, the system can send an authorization request message to the authorization computer 110. Based on the applied exemption, the authorization request message can be sent without an authentication operation. The authorization request message can include information indicating the applied exemption (e.g., TRA / WL / OLO / LV, as indicated in Figure 11 ).

[0190] In step 1010, the authorization computer 110 may perform an authorization operation. The authorization computer 110 may perform the authorization operation by utilizing data received from the server computer 310. For example, the authorization computer may determine to authorize an access request simply based on the received access indicator, as described above with respect to Figure 8 as described. Alternatively or additionally, the authorization computer 110 may determine whether to authorize an access request by analyzing the received data according to its own rule set.

[0191] If the authorization computer 110 determines not to authorize the access request, then in step 1014, the authorization computer 110 may notify the messaging module 104F as needed that access to the resource is denied. The authorization computer may transmit the notification via an authorization response message.

[0192] In step 1012, the authorization computer 110 may transmit the authorization result to the post-authorization module 104J. In the case of a payment transaction, the authorization result may include an indication of whether sufficient funds are available in the payment account. The authorization result may include an address verification service (AVS) check result. The AVS check may be performed after analyzing some or all of the addresses submitted in the access request. When determining the authorization result, the authorization computer 110 may compare the address data with the archived address data associated with the account. For example, a cardholder may be prompted to enter their zip code when purchasing gasoline. By comparing the received zip code with the stored zip code associated with the payment account, the authorization computer 110 may use this zip code for authorizing the transaction. The authorization result may include a card verification number (CVN) check result. The CVN is a three- or four-digit code associated with the payment account. The authorization computer may determine whether the CVN received in the authorization request message matches the value archived by the authorization computer. As another example, the authorization result may include confirmation that the user has a valid credential to enter a secure location.

[0193] In step 1016, the post-authorization module 104J may analyze the information received from the authorization computer 110. The post-authorization module 104J may itself determine whether access to the resource should be granted. This determination may be based on the information received from the authorization computer 110 (e.g., AVS, CVN, or funds availability information). The determination may also be based on additional information available to the server computer (which the authorization computer 110 may not have access to), such as access data, access rules, access scores, etc. Thus, in some cases, the post-evaluation module may make a determination different from that of the authorization computer 110.

[0194] In step 1016, the post-authorization module may transmit the final result to the messaging module 104F. The result may be to allow (accept) access to the resource. The result may be to deny access to the resource. The result may be to further review the request.

[0195] After step 1016, based on information received from the authorization computer 110 and / or the post-authorization module 104J, the messaging module 104F may initiate appropriate actions. If any entity has determined to deny the access request, the messaging module 104F may transmit an instruction to the access device to deny access. If the entities have both determined to approve, the messaging module 104F may transmit an instruction to the access device to grant access. If the post-authorization module determines that a review should be conducted, the messaging module 104F may transmit an instruction to the server computer to initiate a manual review process.

[0196] D. Hybrid screening, no exemptions

[0197] With respect to Figure 11 A method for screening hybrid pre-authorization access requests without exemptions is described. Figure 11 The operations shown in Figures 1 to 2B may be performed by the server computer 104, the authentication computer 116, and the authorization computer 110 shown in

[0198] In step 1102, the messaging module 104F makes a call to the access request analyzer module 104E, as described above with respect to Figure 11 step 1002. The access request analyzer module 104E may then select and transmit a data file to the exemption module 104I in step 1104, as described above with respect to Figure 10 step 1004.

[0199] In step 1106, optionally, the system may deny the authorization request after selecting the data file, as described above with respect to Figure 10 step 1006.

[0200] In step 1108, the exemption module may determine that no exemptions apply. The exemption module may determine that no exemptions apply by comparing the received data file and / or access data with the exemption rules. After determining that no exemptions apply, the exemption module may transmit an authentication request message to the authentication computer, which may explicitly or implicitly specify that no exemptions apply.

[0201] In step 1110, the enrollment module 116E of the authentication computer may perform a BIN detection operation. The enrollment module may identify the BIN from the data received in the authentication request message. Based on the BIN, the enrollment module may determine how to process the authentication. This may include determining the enrollment status of one or more entities involved (e.g., whether the user, issuer, or merchant is enrolled in the security authentication protocol).

[0202] In step 1112, the registration module 116E may transmit an instruction to the verification module 116F to perform an authentication operation. The instruction may include a specified authentication level (i.e., based on exemption, registration status, access data, and / or the like, standard or enhanced authentication measures may be invoked).

[0203] In step 1114, the verification module 116F may perform the authentication operation. The verification module 116F may perform the authentication operation substantially as described above with respect to Figures 3 to 8 the description.

[0204] In step 1116, the verification module 116F may transmit authentication data such as an authentication result, CAVV, ECI, and / or the like to the messaging module 104F. In step 1118, the messaging module 104F may forward the authentication data (e.g., ECI / CAVV) to the access request analyzer module 104E.

[0205] In step 1120, the access request analyzer module 104E may perform a risk screening based on the received authentication data. The access request analyzer module 104E may perform a risk screening based on the authentication data as described above with respect to Figure 10 the description.

[0206] In step 1124, the access request analyzer module 104E may transmit an authorization request message to the authorization computer 110. The authorization request message may include the authentication data received from the authentication computer 116 (e.g., CAVV, ECI, authentication result, etc.). The authorization request message may also include information related to the risk screening performed by the request analyzer module, such as an access indicator, an access score, access data, etc.

[0207] In step 1126, the authorization computer performs an authorization operation. The authorization computer may perform the authorization operation substantially as described above with respect to Figure 10 step 1010. If the authorization computer 110 determines to reject, the authorization computer may transmit an authorization response message to the messaging module 104F indicating that the access should be denied.

[0208] In steps 1128 and 1132, the post-authorization module 104J may perform a post-authorization screening and send its result, substantially as described above with respect to Figure 10 steps 1012 and 1016.

[0209] E. Hybrid Screening in Combination with Exemption

[0210] With respect to Figure 12 a method for hybrid pre-authorization access request screening in combination with exemption is described. Figure 12 The operations shown in Figures 1 to 2Bexecuted by the server computer 104, authentication computer 116, and authorization computer 110 shown in

[0211] In step 1202, the messaging module 104F invokes the access request analyzer module 104E, as described above with respect to Figure 10 step 1002. The access request analyzer module 104E may then, in step 1204, select and transmit a data file to the exemption module 104I, as described above with respect to Figure 10 step 1004.

[0212] In step 1206, optionally, the system may deny the authorization request after selecting the data file, as described above with respect to Figure 10 step 1006.

[0213] In step 1208, the exemption module may determine that one or more exemptions apply. The exemption module may determine that an exemption applies by comparing the received data file and / or access data with exemption rules. However, the exemption module 104I may also determine that an exemption should be omitted. The exemption module 104I may use access rules to determine that, in certain situations, the exemption should be overridden. For example, even though the transaction is less than $100, if the transaction originated in China, the exemption should not apply. The risk rules may be configured such that the system authenticates and uses the authentication result for further analysis. The exemption module 104I may then transmit a notification to the authentication computer indicating that the exemption should be omitted.

[0214] Steps 1210 to 1232 may be performed in substantially a similar manner as described above with respect to Figure 11 steps 1110 to 1132. Since the exemption is omitted, the system may continue as if no exemption applied, substantially.

[0215] F. Exemption Override

[0216] with respect to Figure 13 described is a method for screening hybrid pre-authorization access requests where the exemption is overridden by the authentication computer. Figure 13 The operations shown in Figures 1 to 2B may be performed by the server computer 104, authentication computer 116, and authorization computer 110 shown in

[0217] In step 1302, the messaging module 104F invokes the access request analyzer module 104E, as described above with respect to Figure 10 step 1002. The access request analyzer module 104E may then, in step 1304, select and transmit a data file to the exemption module 104I, as described above with respect to Figure 10 step 1004.

[0218] In step 1306, optionally, after selecting the data file, the system may reject the authorization request as described above with respect to Figure 10 step 1006.

[0219] In step 1308, the exemption module may determine that one or more exemptions apply, as described above with respect to Figure 12 . Accordingly, the system may transmit the authorization request message to the authorization computer 110 without first performing an authentication operation. The authorization request message may include an indication that an exemption has been applied and / or that authentication has not been performed. The authorization request message may also include the access data and other information about the access request.

[0220] In step 1310, the authorization computer 110 may analyze the received data. The authorization computer 110 may determine that authentication is required based on the rules of the authorization computer.

[0221] In step 1312, the authorization computer 110 may transmit a message indicating that authentication is required to the registration module. Based on the received message, the authentication computer may perform an authentication operation before resubmitting the authorization request message, indicating that authorization has been completed.

[0222] Steps 1314 to 1332 may be performed in substantially a similar manner as described above with respect to Figure 12 steps 1110 to 1132.

[0223] V. Advantages

[0224] The teachings of the present disclosure have many advantages. For example, the authorization computer may increase confidence and improve the authorization rate by leveraging access indicators in the authorization decision. The issuer may be more inclined to authorize an access request when convinced that the trusted entity has screened the access request for fraud. By reducing the unnecessary denial of access grants, users are more motivated to make authorization requests through the corresponding channels. Additionally, increased access can lead to increased revenue.

[0225] Furthermore, by using authentication data for access determination, the accuracy of these determinations can be improved. Authentication data, especially risk-based authentication data, can be extremely useful in calculations for performing fraud checks and authorization-side risk checks. Many of these data elements are typically not available to the authorization computer. Transmitting the authentication details to the authorization computer also more clearly differentiates the risk levels, enabling the authorization computer to fine-tune access determinations. Additionally, adding authentication and / or access details to a dedicated message field of the authorization computer can improve compatibility with the issuer's authorization risk engine.

[0226] Accordingly, the accuracy of fraud detection can be greatly increased. The methods described herein can both increase the number of fraudulent access attempts intercepted and decrease the number of false rejections of access requests that are not actually fraudulent.

[0227] Embodiments of the present disclosure have many additional examples. For example, an authorization computer can utilize the data and computations of an authorization computer and / or a server computer to evaluate an access request. The authorization computer can reduce or even eliminate the amount of computation required, thus saving time and computing resources. The authorization computer can also greatly reduce the amount of data storage required. Additionally, by using a pre-existing authorization request message to transmit the data, the system is not burdened with additional messaging operations.

[0228] Although examples have been described in the context of payment transactions, the methods described herein are applicable to other contexts. As an example, some embodiments can be used to determine whether to grant access to a secure lockbox. As another example, some embodiments can be used to determine whether to allow a user to log in to a secure website.

[0229] VI. COMPUTER SYSTEM

[0230] Figure 14 is a high-level block diagram of a computer system 1400 that can be used to implement any of the entities or components described above.

[0231] Figure 14 The subsystems shown in are interconnected by a system bus 75. Additional subsystems are shown, such as a printer 74, a keyboard 78, a storage device 79, a monitor 76 coupled to a display adapter 82, etc. Peripheral devices and I / O devices coupled to an input / output (I / O) controller 71 can be connected to the computer system by any number of components known in the art - for example, a serial port 77. For example, the serial port 77 or an external interface 81 (such as Ethernet, Wi-Fi, etc.) can be used to connect the computer system 10 to a wide area network such as the Internet, a mouse input device, or a scanner. The interconnection via the system bus 75 allows the central processor 73 to communicate with each subsystem and control the execution of instructions from the system memory 72 or the storage device 79 (e.g., a fixed disk such as a hard disk drive or an optical disc), as well as the exchange of information between the subsystems. The system memory 72 and / or the storage device 79 can embody computer-readable media. Any data mentioned herein can be output from one component to another and can be output to the user.

[0232] It should be understood that any of the embodiments can be implemented in the form of control logic using hardware (e.g., application specific integrated circuit or field programmable gate array) and / or in a modular or integrated manner using computer software by a generally programmable processor. As used herein, a processor includes a multi-core processor on the same integrated chip, or multiple processing units on a single circuit board or networked. Based on the disclosures and teachings provided herein, those of ordinary skill in the art will know and understand other ways and / or methods of implementing the embodiments using hardware as well as combinations of hardware and software.

[0233] Any software component or functionality described in this application can be implemented as software code executed by a processor using any suitable computer language such as Java, C, C++, C#, or a scripting language such as Perl or Python using, for example, conventional or object-oriented techniques. The software code can be stored on a computer-readable medium as a series of instructions or commands for storage and / or transmission, suitable media including random access memory (RAM), read-only memory (ROM), magnetic media such as a hard disk drive or floppy disk, or optical media such as a compact disc (CD) or digital versatile disc (DVD), flash memory, etc. The computer-readable medium can be any combination of such storage or transmission devices.

[0234] Such programs can also be encoded and transmitted using a carrier signal suitable for transmission via wired, optical, and / or wireless networks—including the Internet—compliant with various protocols. Thus, a computer-readable medium according to an embodiment can be generated using a data signal encoded by such a program. A computer-readable medium encoded by 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 in a system or network. The computer system can include a monitor, printer, or other suitable display for providing any of the results mentioned herein to a user.

[0235] Any of the methods described herein can be performed, in whole or in part, by a computer system including one or more processors configured to perform the steps. Thus, embodiments can relate to computer systems configured to perform the steps of any of the methods described herein, which may have different components for performing the corresponding steps or groups of corresponding steps. Although presented in numbered steps, the method steps herein can also be performed simultaneously or in a different order. Additionally, portions of these steps can be used in conjunction with portions of other steps from other methods. Furthermore, all or part of the steps can be optional. Additionally, any step of any method can be performed by a module, circuit, or other means for performing these steps.

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

[0237] The above description is illustrative and not restrictive. Many variations will be apparent to those skilled in the art upon review of the present disclosure. Accordingly, the scope should not be determined with reference to the above description, but instead should be determined with reference to the pending claims and their full scope or equivalents.

[0238] The recitation of "a" or "the" is intended to mean "one or more" unless explicitly indicated to the contrary.

[0239] All patents, patent applications, publications, and descriptions mentioned above are incorporated herein by reference in their entirety for all purposes. It is not admitted that they are prior art.

Claims

1. A method for access request screening, the method comprises: receiving, by a server computer, a request from a requesting device for a user device to access a resource, the request including access data; transmitting, by the server computer, an authentication request message to an authentication computer, the authentication request message including at least a subset of the access data; receiving, by the server computer, an authentication response message including authentication data from the authentication computer, wherein the authentication computer generates the authentication data based on at least a subset of the access data, and wherein the authentication data includes an authentication code indicating an authentication result and an authentication password; determining, by the server computer, an access score based on at least a subset of the access data and the authentication data; comparing, by the server computer, the access score with one or more thresholds to determine whether to send an authorization request message to an authorization computer if the access score reaches or exceeds the threshold; generating, by the server computer, an access indicator based on the access score; preparing, by the server computer, an authorization request message including the access indicator, the authentication code, and the authentication password; and transmitting, by the server computer, the authorization request message to the authorization computer, wherein the authorization computer approves or rejects the access of the user device to the resource based on the access indicator and the authentication data included in the authorization request message.

2. The method according to claim 1, wherein the access indicator includes a flag indicating that the server computer has approved the access request.

3. The method according to claim 1, wherein: the authentication data includes supplementary data; and the authorization request message further includes the supplementary data.

4. The method according to claim 1, further comprises: analyzing, by the server computer, the access data against a plurality of exemptions, wherein if one or more of the plurality of exemptions apply to the access data, authorization is not required; and determining, by the server computer, based on the access data, that no exemption applies to the access request.

5. The method according to claim 1, wherein the access indicator is transmitted in an open data field of the authorization request message.

6. The method according to claim 1, wherein, comparing, by the server computer, the access score with one or more thresholds includes: identifying a first threshold corresponding to an access request that should be approved; identifying a second threshold corresponding to an access request that should be rejected; comparing the access score with the first threshold and the second threshold; and determining that the access score exceeds the first threshold and the second threshold.

7. The method according to claim 1, further comprises: analyzing, by the server computer, the access data against a plurality of exemptions, wherein if one or more of the plurality of exemptions apply to the access data, authorization is not required; determining, by the server computer, based on the access data, that one or more exemptions apply to the access request; and Transmit the authorization request message without performing an authorization operation based on the determination.

8. A method for access request screening, the method comprising: Receiving, by a server computer, a request from a requesting device for a user device to access a resource, the request including access data; Transmitting, by the server computer, an authentication request message to an authentication computer, the authentication request message including at least a subset of the access data; Receiving, by the server computer, an authentication response message from the authentication computer, the authentication response message including authentication data corresponding to an authentication level of the authentication computer for the user device, wherein the authentication computer generates the authentication data based on the access data, and wherein the authentication data includes an authentication code and an authentication password indicating an authentication result; Determining, by the server computer, an access score based on the authentication data and the access data; Determining, by the server computer, whether to send an authorization request message to an authorization computer by comparing the access score with one or more thresholds, such that based on the access score, it is determined whether to transmit the authorization request message to the authorization computer; and Transmitting the access score to the authorization computer, wherein the authorization computer approves or rejects the access to the resource based on the access score.

9. The method according to claim 8, further comprising: Generating an access indicator based on the access score; and Transmitting the access indicator to the authorization computer, wherein the authorization computer approves or rejects the access to the resource based on the access indicator.

10. The method according to claim 9, wherein the access indicator is transmitted in an open data field of the authorization request message.

11. The method according to claim 9, wherein the access indicator includes a flag indicating that the server computer has approved the access request.

12. The method according to claim 8, further comprising: Before transmitting the authentication request message: Analyzing, by the server computer, the access data against a plurality of exemptions, wherein if one or more of the plurality of exemptions apply to the access data, authorization is not required; and Determining, by the server computer based on the access data, that no exemption applies to the access request.

13. The method according to claim 8, further comprising: Before transmitting the authentication request message: Analyzing, by the server computer, the access data against a plurality of exemptions, wherein if one or more of the plurality of exemptions apply to the access data, authorization is not required; Determining, by the server computer based on the access data, that one or more exemptions apply to the access request; Transmitting an authorization request message to the authorization computer, the authorization request message including an indication that an exemption from the plurality of exemptions has been applied; and Receiving an indication from the authorization computer that the exemption has been overridden and authentication is required.

14. A server computer, comprising: A processor; and A non-transitory computer-readable medium coupled to the processor, the non-transitory computer-readable medium including code that can be executed by the processor to implement the method according to any one of the above claims.

15. A computer product including a computer-readable medium storing a plurality of instructions for controlling a computer system to execute the method according to any one of claims 1 to 13.

Images