Contextual and time sensitive out of band transactional signing

Provided is contextual and time sensitive out of band transactional signing. The transactional signing includes providing a token code in response to a request to initiate a transaction within a secure network. The request is received over a first channel and the token code is provided over a second channel. The first channel and the second channel are different channels. The transactional signing also includes evaluating a received context, wherein the context is appended to the token code. In addition, the transactional signing includes selectively allowing the transaction based on the context appended to the token code.

BACKGROUND

Authentication is the process of determining whether a person is the actual person they are asserting themselves to be. A common type of authentication is based on logon passwords or other credentials. As it relates to financial institutions, for example, a customer may access and transact with one or more of the customer's financial institution(s) accounts through a variety of channels. As non-limiting examples, a customer's physical credit card may be used to make purchases at a point of sale and/or a credit card number may be used to make purchases online. In other examples, the customer's account information may be accessed and viewed through a financial institution website, the customer may manage an account through a telephone interaction, and so on. Although these options provide increased access and convenience for the customer, each of these channels also provide opportunities for fraudulent access. On the user side, an occurrence of fraud (e.g., compromised financial data, monetary loss, identity theft, and so on) as well as the need to provide authentication information (e.g., enter a temporary pass code or one time password) have been blamed for user dissatisfaction. On the network side, malware that operates to intercept the temporary pass code or one time password makes it increasingly difficult to authenticate devices and users associated with the devices with a high degree of confidence.

SUMMARY

An aspect relates to a system that includes a processor that executes computer executable components stored in a memory. The computer executable components may include a security manager component that transmits a token code and a security question in response to an indication of a transaction attempt within a secure site. The indication is received over a first communications channel and the token code and the security question are transmitted over a second communications channel different from the first communications channel. The system also includes an authorization manager component that analyzes a reply to the security question and selectively allows the transaction based on the analysis. The reply is appended to a received token code.

Another aspect relates to a method that may include providing, by a system comprising a processor, a token code in response to a request to initiate a transaction within a secure network. The request is received over a first channel and the token code is provided over a second channel. The first channel and the second channel are different channels. The method may also include evaluating, by the system, a received context, wherein the context is appended to the token code. Further, the method may include selectively allowing, by the system, the transaction based on the context appended to the token code.

Yet another aspect relates to a computer-readable storage device storing executable instructions that, in response to execution, cause a system comprising a processor to perform operations. The operations may include receiving, over a first communications channel, an indication of a transaction attempt within a secure site and transmitting, over a second communications channel different from the first communications channel, a token code and a security question. The operations may also include receiving a reply to the security question and selectively allowing the transaction based on analysis of the reply. The reply is appended to the token code.

DETAILED DESCRIPTION

The innovation is now described with reference to the drawings. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the subject innovation. It may be evident, however, that the innovation may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate describing the innovation.

FIG. 1illustrates an example, non-limiting representation of a communications environment100in which the disclosed aspects may be utilized. The communications environment100includes an initiating device102that is attempting to perform one or more transactions within a secure site104. The initiating device102may be a communication device (e.g., desktop computer, laptop computer, smart phone, and so on). The secure site104may be a network associated with an entity, for example. As used herein an “entity” refers to a financial institution, such as a bank, persons operating on behalf of the financial institution, and/or communication devices managed by the financial institution and/or the persons operating on behalf of the financial institution. Additionally or alternatively, the entity may be a third party monitoring source, security provider, or another type of entity that has a trusted relationship with the financial institution.

Also illustrated in the environment100is an authorization entity106. Although illustrated as separate from the secure site104, according to some implementations, the authorization entity106may be communicatively coupled to the secure site104. For example, the authorization entity106may be a trusted third party that performs authorization functions on behalf of the secure site104(e.g., an entity associated with the secure network). In another example, the secure site104may be configured to perform the authorization functions (e.g., the authorization entity106is included in the secure site104).

According to various aspects disclosed herein, contextual and time sensitive out of band transactional signing is provided. The transactional signing as discussed herein may be applied when a user (e.g., through the initiating device102) attempts to log in to access a website or other secure site104, such as a financial institution website, from an unrecognized device or location. The transactional signing may also be applied when a user (or the initiating device102) is attempting to log in through an unrecognized or suspicious Internet Protocol (IP) address, such as, for example, when the user is making an out of band log in attempt. In another example, the transaction signing may be applied based on user preferences, preferences of the secure site, or other considerations.

In some traditional systems, the user may be required to enter a one-time passcode (OTP) or other authentication code generated by a recognized/strongly bound device in order to proceed to log in through an unrecognized channel (e.g., unrecognized device). However, such traditional systems may be compromised with malware (resident on the user device) that operates to intercept the OTP or code. The various aspects disclosed herein are configured to mitigate the chances of a rogue entity intercepting the code or otherwise gaining access to, or performing transactions within, the secure site104. Therefore, the occurrence of fraud and other undesirable activities may be mitigated.

According to an implementation, an additional factor (or more than one additional factor) may be added to an input received from the initiating device102. Additional factors may include, but are not limited to, the context of the transaction being made through the initiating device. For example, the context may be a current location of the user (e.g., initiating device), a behavior pattern of the user, a consideration of whether the user is performing a normal activity for the user or an activity that is abnormal for the user, and so on. In other examples, the context may be a monetary value of the transaction, a name of a recipient of a monetary transaction, and so forth. According to some aspects, the user may be provided a choice or a range of options from which to choose. Based on the selection, the context from the transaction may be appended to the token code, which may be performed dynamically by the initiating device102.

By combining the contexts or factors with the token code, the authorization entity106may selectively allow the initiating device102to proceed with the attempted transaction with the secure site104. According to the aspects discussed herein, the user is not required to input the code on a desktop environment, for example. Thus, if the token code is “12345,” the user is not responding back with “12345.” Instead, one or more contexts (or one or more factors) are appended to the token code “12345” (according to this example) and the combination is conveyed from the initiating device102to the authorization entity106. In the case of a rogue entity, the rogue entity may not be able to supply the correct contexts or factors and, thus, the transaction may be denied.

Further, there may be at least one temporal aspect associated with the token code. For example, at about the same time as the code and security question(s) (or a range of questions) are transmitted, a timer may be initiated. The value of the timer may be predetermined based on various considerations such as the amount of time needed to convey the information, an amount of time for the information to be entered by the user (or automatically applied by the initiating device102), the amount of time needed to transmit the reply, and so on. According to some aspects, the value of the timer may be configurable such that traffic delays, network delays, and other considerations may be factored into the timer value. If a reply is received prior to the expiration of the timer, the reply may be considered, as discussed herein. However, if the timer expires, then too much time has elapsed and the transaction is automatically denied. In this situation, a subsequent transaction will be initiated.

According to an implementation, a user logs into an online banking website (e.g., in a desktop environment). The user initiates a non-monetary event. For example, the user may be updating his profile information (e.g., address, phone number, and so on), changing features or options, and so forth. The system100may make a determination based on these events, such as determining that the transaction attempt is an out of band authentication, and a code is conveyed to the user. The user device (e.g., the initiating device102) receives the code and appends a context identifier that is relevant to the transaction to the code. For example, if the transaction is an email address update, the user (through the user device) may receive one or more options to select and the user device can append the context to the token code based on the user's selection. The user responds to the server (e.g., the system100) through a trusted device (in this example, the trusted device is a banking application executing on a mobile device or the initiating device102). The server may automatically respond to an identification of the context plus the details provided by the user. Based on confirmation, the user may be allowed to continue the transaction on the mobile device, which may be presented to the user based on a screen refresh that indicates the transaction is allowed. There is no point in this process where the user takes the code and puts the code in their desktop environment.

In accordance with another implementation, a user logs into the secure site104, which may be an online banking website (e.g., in a desktop environment). The user initiates a monetary event. The system100makes a determination that an out of band authentication is necessary. In the context of monetary events, the user device, or the initiating device102appends the transaction details to a token code, which may be performed automatically, without user interaction. The transaction details may be the type of transaction (e.g., wire transaction, transfer of funds, and so), the destination, the amount, details of a beneficiary, or other information. The system100, upon receipt of this information may selectively allow the transaction. No additional input is necessary from the user on a desktop environment. Thus, the user receives the challenge and uses the same mobile channel to respond and the system makes a determination whether the response is valid or is not valid. Further, the system or user device automatically triggers a refresh on the screen or performs another type of graphical user interface change, which allows the user to continue.

According to another implementation, the system100may detect a high-value monetary transaction request. To make a determination as to whether the transaction request is real or is a fraudulent request, the system may send a mandate to the user. The mandate may be for the user to provide information related to a merchant type (e.g., brick and mortar store, website, or another type), details of the merchant (e.g., name, phone number, physical address, website address, and so on), the transaction value, or other identifying information. The details may be provided in a financial application executing on the user device, which may be at the same location as the transaction location (e.g., at a store) or at a different location (e.g., over the Internet).

The application executing on the user device may be reviewed in real-time and a determination whether to approve or not approve the transactions is performed. The determination may be made based on a subset of the details provided. For example, the mandate may be for the user to provide five different types of details and, at substantially the same time as the details for the five types are received, a subset (e.g., two types, three types) are chosen for analysis. The subset may be chosen as the types that are considered more critical for the current transaction (and might not be the same types used for another transaction). At substantially the same time as the details related to at least the subset are analyzed, a determination may be made related to whether the code received with the details is the correct code.

According to some implementations, a challenge is not presented to the user. Instead, the user's pattern is determined based on historical information associated with the user. Such historical information may include a location of the user and/or transaction, a transaction pattern, a transaction type, a transaction amount, and other data. If a current transaction matches known transactions from the historical information (e.g., is within an expected range and/or an acceptable range), the current transaction may be automatically allowed.

Further, when the financial application is executing on the user device, the two-way communication process may be automatically implemented. In accordance with some aspects, the system may obtain data directly from the user device without needing manual input from the user. At other times, however, input from the user might still be needed and the user may be provided a variety of options as to the information provided in real-time.

According to another implementation, a two-way communication may be established through a downloadable application executing on the user device. The downloadable application may be configured to extract details related to the user device automatically. For example, the user may authorize the application to automatically extract details x, y, and z from his device. The details that may be extracted may be preset application permission values. Thus, without the user needing to open the application, a two-way communication is established and information related to a location and/or activities of a user are automatically provided to the authentication manager component. In accordance with one or more implementations described in this disclosure, users can opt-out of providing personal information, demographic information, location information, proprietary information, sensitive information, or the like in connection with data gathering aspects.

In an example, the financial institution or other entity may make a determination that the details of the user and behavior pattern are known based on automatic payments sitting on the user device. Further, the determination may be made based on the user having provided permission for the financial institution or other entity to interact with the values on the user device, wherein the values are extracted to make the determination. If the values match, the transaction is allowed. If there is a mismatch in any of the information, then an OTP process can be implemented and a context is provided, as discussed herein.

FIG. 2illustrates an example, non-liming implementation of a system200configured for out of band authentication, according to an aspect. As discussed above, traditional out of band verification processes may request a user to input a code that is distributed on the user's mobile device and for verification purposes, wherein the code needs to be input on a device other than the mobile device. A challenge associated with these traditional approaches is that a typical form of malware may easily defeat the verification process.

To overcome the above-described challenges as well as other challenges associated with conventional approaches, various aspects disclosed herein relate to removing the complexity from a user's input into a client application and in response to receipt of a token code. Elimination of the need for user input on the client application side may mitigate malware interception of the code.

The system200may include at least one memory202that may store computer executable components and/or computer executable instructions. The system200may also include at least one processor204, communicatively coupled to the at least one memory202. The at least one processor204may facilitate execution of the computer executable components and/or the computer executable instructions stored in the memory202. The term “coupled” or variants thereof may include various communications including, but not limited to, direct communications, indirect communications, wired communications, and/or wireless communications.

It is noted that although the one or more computer executable components and/or computer executable instructions may be illustrated and described herein as components and/or instructions separate from the memory202(e.g., operatively connected to the memory202), the various aspects are not limited to this implementation. Instead, in accordance with various implementations, the one or more computer executable components and/or the one or more computer executable instructions may be stored in (or integrated within) the memory202. Further, while various components and/or instructions have been illustrated as separate components and/or as separate instructions, in some implementations, multiple components and/or multiple instructions may be implemented as a single component or as a single instruction. Further, a single component and/or a single instruction may be implemented as multiple components and/or as multiple instructions without departing from the example embodiments.

The system200may also include a security manager component206that may be configured to transmit a token code208and a security question210(or a set of security questions) in response to an indication212of an attempt to perform a transaction within a secure site104. The indication212may be received from an initiating device102, as illustrated. Alternatively, the indication may be received from the secure site104.

The transaction may be a non-monetary transaction (e.g., user profile, preferences, accessing forms, and so on) or a monetary transaction (e.g., viewing account balances or transactions, transferring money, wiring money, making a payment, depositing funds, and other financial transactions).

The communication between the system200and the initiating device102may be an out of band communication (e.g., a communication on a different channel, or by a different method, than the channel or method of the primary communication channel). As used herein, the out of band communication will be referred to as different communication channels. Therefore, the indication212may be received over a first communications channel214and the code208and the security question(s)210may be transmitted over a second communications channel216. The first communication channel214and the second communications channel216may be different channels. For example, the initiating device102may be a desktop computer, wherein a user has logged into the secure site104. Therefore, the indication212of the transaction is received from the desktop computer. In response, the code208and the security question(s)210may be transmitted through a Short Message Service (SMS), for example.

An authorization manager component218may be configured to analyze a reply220received in response to the security question(s)210. The reply220may be appended to the code208. For example, if the reply220is the expected reply (and includes the code208), the authorization manager component218allows the transaction to continue. However, if the reply220is not the expected reply (and/or the received code is not the code208), the transaction request is denied and/or more information is solicited from the initiating device102.

FIG. 3illustrates another example, non-limiting system300configured to provide contextual and time sensitive out of band multi-channel transactional signing, according to an aspect. An initiating device102may log into a secure site104. For example, the initiating device102may be authorized to access the secure site104based on an initial authorization. This initial authorization may include the entry of a user name and password pair or other manners of signing into a website or providing credentials. However, because the correct credentials were provided and limited access to the secure site is allowed, an entity performing a subsequent transaction within the secure site might be someone other than the authorized user (e.g., man in the middle attack). A man in the middle attack occurs when a rogue entity (e.g., attacker) relays and/or alters a communication between two parties (e.g., a user associated with the initiating device102and the secure site104). However, the two parties mistakenly believe they are communicating with each other.

To overcome man-in-the middle and other unauthorized access and/or transactions with the secure site104, a communication component302may be configured to receive a transaction indication212. For example, after logging into the secure site104, the initiating device102(or user thereof) may attempt to perform a transaction, which may be a monetary transaction or a non-monetary transaction. The transaction indication212may be received from the initiating device102, the secure site104, or an associated device. Further, the communication component302may be configured to determine a communication channel214over which the transaction indication212is received.

Based on the transaction indication212, a generation component304may be configured to produce a code208(e.g., token code). In addition to generating the code208, the generation component304may be configured to generate one or more security questions210in response to the transaction indication212. In some implementations, the one or more security questions210may include a range of questions, wherein one or more of the questions within the range may be selected and answered at the initiating device102. The one or more security questions210may relate to the transaction being attempted, information related to the user (that only the user would know), and so on.

Further, the security manager component206(or the communication component302) may be configured to transmit the code208and the security question(s)210at substantially the same time in response to the transaction indication212. The transmission by the security manager component206(or communication component302) may be over a second communication channel216, different from the communication channel214. Thus, the communication channel216used to convey the code208and the security question(s)210is not associated with the communication channel214that was used to convey the initial request (e.g., the transaction indication212).

The authentication manager component218may be configured to evaluate a reply220received from the initiating device102. The reply220may include one or more answers to the security question(s)210. The one or more answers may be appended to the code208. Thus, the initiating device102may be configured to combine the code208and the answers to the security question(s)210.

At about the same time as the reply220is received, the authentication manager component218may be configured to determine whether the transaction should be allowed, should be denied, or whether additional information should be retrieved from the initiating device102. For example, if the response(s) to the question(s) are the expected response(s), the authentication manager component218may allow the transaction. However, if the response(s) are not as expected, the authentication manager component218may deny the transaction. Alternatively, if the response(s) are not the expected responses, additional information may be solicited from the initiating device102(e.g., through interaction with the security manager component206or another system300component).

The authentication manager component218may be configured to convey the decision306to the initiating device102in a format that is automatically applied at the initiating device102. For example, the decision306may be applied as a refresh on a screen of the initiating device102or as another type of graphical user interface (GUI) change or update.

FIG. 4illustrates another example, non-limiting system400configured for dynamic contextual and time sensitive out of band transactional signing, according to an aspect. At about the same time as a transaction indication212is received from an initiating device102, over a first communications channel214, a generation component304may be configured to create a token code208. Further, the communication component302may be configured to transmit one or more security questions to the initiating device102. The token code208and the one or more security questions210may be transmitted to the initiating device102over a second communications channel216, different from the first communications channel214. According to some implementations, the one or more security questions210are provided in the form of a choice or range of options that may be selected by the user.

For example, the questions may related to the context of the transaction. Thus, the context of a transaction may be appended to the token code (by the initiating device102) and this combination is a one-time value code. The information included in the reply220is processed by the authentication manager component218. According to an implementation, a historical module402may be configured to gather historical details related to the initiating device102(and the user of the initiating device102). For example, details related to transactions performed by the initiating device102may be captured over a period of time and the transaction details may be retained in a database associated with the historical module402. When the reply220is received, information included in the reply220may be compared, by the authentication manager component218, to the known historical information. If the information matches, it may indicate that the user of the initiating device102may be verified to perform the current transaction.

To match the reply220with the historical information, the authentication manager component218may make a determination whether the user normally performs the type of transaction being attempted. The details related to the current transaction may be extracted in real time and can be combined to issue a challenge and subsequently verify the user.

In an implementation, the initiating device102may add the details without input from the user. For example, the system400may know whether the device is a known good device (e.g., a verified device) or whether the authenticity of the device is unverified. Thus, the context may be added to the token code208, wherein the token code208was provided to the initiating device102over a channel216that is different than the channel214used to convey the transaction request212from the initiating device102.

According to some implementations, the context may be extracted based on a downloadable application that is executed on the initiating device102. The application may have a two-way communication path. Further, the application may initiate an arbitrator state to provide the secure site104and/or the security manager component206information about a state of the initiating device102without requiring intervention from the user of the initiating device102. For example, the application may be configured to determine a geographic location of the initiating device102, or may interact with another component, such as a global positioning system or another location means installed on (or associated with) the initiating device102. Further, the application (or another system component) may determine the internet protocol address that is used by the initiating device102and the authentication manager component218may determine if the current internet protocol address matches a historical internet protocol address used by the initiating device102.

In an example, both the internet protocol details and the location coordinates are utilized by the authentication manager component218to verify the user (e.g., the initiating device102). For example, it may be possible for a rogue device to use fake internet protocol addresses or proxies to mask the application details. Thus, by combining both details, it is possible to obtain a greater degree of confidence that the request is originating from the appropriate device.

In accordance with some implementations, at about the same time as the token code208and the one or more security questions210are transmitted, a timer404may be activated. The timer404may be configured to determine an amount of time that elapses from transmission of the token code208and the one or more security questions210to receipt of a reply220at the authentication manager component218.

According to an aspect, information related to a user's login attempt may be considered when determining what level of user input should be received for out of band verification. Such information may include a geographical location (geolocation) of the user, internet behavior, device risk, and so on. If, based on an analysis of the information, it is determined that the user should provide a higher level of verification, the user is provided an OTP or other verification code on a channel that is different from the channel from which the user is attempting to log in. For example, if the user is logging in through a desktop computer, the user may be provided with the OTP though a Short Message Service (SMS) message. The user may then provide the OTP/verification code in conjunction with a user-specific signature that is used by the security of the website to verify that the user is providing the authentication information.

The signature may be generated by the user (e.g., the user device) and may be specific to the context in which the user is required to provide the signature. For example, if the user is attempting to log in from an unknown device at the user's home, the user may be asked to provide a voiceprint or iris scan. On the other hand, if the user is attempting to access the website from an open network in a noisy public location (e.g., a stadium), other sources of user signatures may be required. These other sources may include a fingerprint scan, entering information only the user would know (e.g., mother's maiden name). The OTP and signature combination required for authentication may be time and context sensitive. Thus, if a user takes too long or moves to a different location, for example, the requested OTP/signature combination may no longer be valid.

According to some implementations, automated learning may be employed to facilitate one or more of the disclosed aspects. For example, a machine learning and reasoning component406may be utilized to automate one or more of the disclosed aspects. The machine learning and reasoning component406may employ automated learning and reasoning procedures (e.g., the use of explicitly and/or implicitly trained statistical classifiers) in connection with determining whether a user device may be authenticated for a specific transaction in accordance with one or more aspects described herein.

For example, the machine learning and reasoning component406may employ principles of probabilistic and decision theoretic inference. Additionally or alternatively, the machine learning and reasoning component406may rely on predictive models constructed using machine learning and/or automated learning procedures. Logic-centric inference may also be employed separately or in conjunction with probabilistic methods.

The machine learning and reasoning component406may infer a potential for fraudulent activity or potential fraud, for example, by obtaining knowledge about various logged information, such as historical data (maintained by a historical module402), which may include error logs and/or the level of errors. For example, if the trend for fraud is higher for a particular transaction type, the machine learning and reasoning component406may automatically require the user to take additional action to complete the authentication, which may also be reflected in a rule-based pattern. In another example, based on a confidence level that user is in fact the authorized user, the machine learning and reasoning component406may automatically authenticate the user and continue to authenticate the user during the entire transaction (or at least a portion of the transaction).

As used herein, the term “inference” refers generally to the process of reasoning about or inferring states of the system, a component, a module, the environment, external devices, mobile devices, and so on from a set of observations as captured through events, reports, data, and/or through other forms of communication. Inference may be employed to identify a specific context or action, or may generate a probability distribution over states, for example. The inference may be probabilistic. For example, computation of a probability distribution over states of interest based on a consideration of data and/or events. The inference may also refer to techniques employed for composing higher-level events from a set of events and/or data. Such inference may result in the construction of new events and/or actions from a set of observed events and/or stored event data, whether or not the events are correlated in close temporal proximity, and whether the events and/or data come from one or several events and/or data sources. Various classification schemes and/or systems (e.g., support vector machines, neural networks, logic-centric production systems, Bayesian belief networks, fuzzy logic, data fusion engines, and so on) may be employed in connection with performing automatic and/or inferred action in connection with the disclosed aspects.

If the machine learning and reasoning component406has uncertainty related to the authentication of the user, the machine learning and reasoning component406may automatically engage in a short (or long) dialogue or interaction with the user (e.g., answer a security question, enter a temporary code, and so on). In accordance with some aspects, the machine learning and reasoning component406engages in the dialogue with the user through another system component and/or an external device.

The various aspects (e.g., in connection with authentication of a user at initiation of a transaction and at various times during the transaction, and so forth) may employ various artificial intelligence-based schemes for carrying out various aspects thereof. For example, a process for determining if particular biological or health factors of a user match an expected value or range of values, or have an unexpected value may be enabled through an automatic classifier system and process.

A classifier is a function that maps an input attribute vector, x=(x1, x2, x3, x4, xn), to a confidence that the input belongs to a class. In other words, f(x)=confidence(class). Such classification may employ a probabilistic and/or statistical-based analysis (e.g., factoring into the analysis utilities and costs) to prognose or infer an action that should be employed to determine the identity of a user.

One or more aspects may employ classifiers that are explicitly trained (e.g., through a generic training data) as well as classifiers that are implicitly trained (e.g., by observing historical patterns related to health, geolocation, devices, and so on). For example, SVM's may be configured through a learning or training phase within a classifier constructor and feature selection module. Thus, a classifier(s) may be used to automatically learn and perform a number of functions, including but not limited to determining according to a predetermined criteria when to automatically authenticate a user (e.g., the initiating device102), which transaction types should have an additional authentication procedure, which transaction amounts should have an additional authentication procedure, and so on.

Additionally or alternatively, an implementation scheme (e.g., a rule, a policy, and so on) may be applied to control and/or regulate when and how a user is authenticated. In some implementations, based upon a predefined criterion, the rules-based implementation may automatically and/or dynamically implement one or more rules and/or confidence levels associated with a particular authentication procedure. In response thereto, the rule-based implementation may automatically interpret and carry out functions associated with the authentication procedure by employing a predefined and/or programmed rule(s) based upon any desired criteria.

Methods that may be implemented in accordance with the disclosed subject matter will be better appreciated with reference to the flow charts. While, for purposes of simplicity of explanation, the methods are shown and described as a series of blocks, it is to be understood and appreciated that the disclosed aspects are not limited by the number or order of blocks, as some blocks may occur in different orders and/or at substantially the same time with other blocks from what is depicted and described herein. Moreover, not all illustrated blocks may be required to implement the disclosed methods. It is to be appreciated that the functionality associated with the blocks may be implemented by software, hardware, a combination thereof, or any other suitable means (e.g. device, system, process, component, and so forth). Additionally, it should be further appreciated that the disclosed methods are capable of being stored on an article of manufacture to facilitate transporting and transferring such methods to various devices. Those skilled in the art will understand and appreciate that the methods could alternatively be represented as a series of interrelated states or events, such as in a state diagram.

FIG. 5illustrates an example, non-limiting method500for out of band authorization, according to an aspect. The method500inFIG. 5may be implemented using, for example, any of the systems, such as the system100(of FIG.1). Computing devices encounter multiple risks, including malware. When an OTP or passcode is provided in response to an attempt to access a secure network, according to traditional methods, the OTP or passcode may need to be entered into an application installed on the computing device (or on another computing device). If there is malware, for example, resident on the computing device, the OTP or passcode is rendered useless because the malware can intercept the code. Thus, the computing device is still open to risk, such as a man in the middle attack.

Thus, method500may be configured to allow the computing device to add a context to the OTP or passcode and submit both at substantially the same time. In some implementations, the OTP or passcode can be relayed to the computing device on a channel that is distinct from another channel that was used to initiate the access request.

Method500starts, at502, when a token code is provided in response to a request to initiate a transaction within a secure network (such as secure site104ofFIG. 1). The request may be received, from a user device (such as initiating device102ofFIG. 1) over a first channel and the token code is provided over a second channel. The first channel and the second channel are different channels. Further, the request may include an indication of an attempt to initiate a transaction with the secure network. The indication may be a request to access a portion of the secure network or to perform another function (e.g., a transaction) within the secure network.

According to an implementation, the request to initiate the transaction may be received after an identity of a user authorized to access to access a secure network is received and verified. For example, the identity of the user may be verified based on a received user name/password pair or another means of identification or credentials (e.g., biometric identification).

At504, a received context is evaluated. The received context may be appended to the token code. Further, the received context may be in reply to the token and may be received from a device that originally initiated the transaction (e.g., the initiating device). However, according to some implementations, the context may be received from a rogue device attempting to commit fraud (and such attempts may be denied, as discussed herein). According to some implementations, the evaluation of the received context may be in reply to one or more challenges or questions, which may be determined based on whether the attempted transaction is a non-monetary transaction or a monetary transaction.

The method500continues, at506, when the transaction is selectively allowed based on the context appended to the code. Selective approval of the transaction may include allowing the transaction, denying the transaction, or requesting additional information and performing another determination as to whether the transaction should be allowed or denied.

For example, the transaction may be approved based on a determination that the context matches at least one parameter of the transaction. In another example, the transaction may be denied based on a determination that the context does not match at least one parameter of the transaction.

FIG. 6illustrates an example, non-limiting method600configured to perform contextual out of band authentication for transactions, according to an aspect. The method600inFIG. 6may be implemented using, for example, any of the systems, such as the system200(ofFIG. 2).

At602, a determination is made whether an attempted transaction is a monetary transaction or a non-monetary transaction. A monetary transaction relates to the viewing, transferring, depositing, withdrawing, or conducting other actions with respect to finances (e.g., bank accounts, loan accounts, credit cards, securities, bonds, stocks, insurance, and so forth). A non-monetary transaction relates to actions that do not directly involve finances, such as changes to a mailing address, a phone number, an email alias, or other actions.

At604, a challenge associated with the transaction is provided. According to an implementation, the challenge may comprise a range of options, wherein at least one option of the range of options comprises a context. For example, if the transaction is a non-monetary transaction, the challenge may relate to information associated with a context of the user (e.g., an answer to a security question, location information, and so on). If the transaction is a monetary transaction, the challenge may related to details about the transaction and/or details associated with the context of the user.

A token code is provided, at606. The token code may be provided at substantially the same time as the challenge is provided. Further, the token code and challenge may be provided over a communications channel that is different from a communications channel over which the indication of the attempted transaction is received.

A context (e.g., a response to the challenge) is received and evaluated, at608. The context may be appended to the token code. In an implementation, evaluating the received context includes comparing the received context to at least one parameter associated with the transaction. According to another implementation, if the token code is not the token code (or an encrypted version thereof) that was sent, at606, the transaction attempt is denied, at610. If the token code matches, the evaluation may include determining if the context matches an expected response. In some implementations, the context may be compared to historical information related to the user and/or user device. If the token code and the context are as expected, the attempted transaction is allowed to continue, at610.

One or more implementations include a computer-readable medium including processor-executable instructions configured to implement one or more embodiments presented herein. An embodiment of a computer-readable medium or a computer-readable device devised in these ways is illustrated inFIG. 7, wherein an implementation700includes a computer-readable medium702, such as a CD-R, DVD-R, flash drive, a platter of a hard disk drive, and so forth, on which is encoded computer-readable data704. The computer-readable data704, such as binary data including a plurality of zero's and one's as illustrated, in turn includes a set of computer instructions706configured to operate according to one or more of the principles set forth herein.

In the illustrated embodiment700, the processor-executable computer instructions706may be configured to perform a method708, such as the method500ofFIG. 5and/or the method600ofFIG. 6, for example. In another embodiment, the processor-executable instructions704may be configured to implement a system, such as the system200ofFIG. 2and/or the system300ofFIG. 3, for example. Many such computer-readable media may be devised by those of ordinary skill in the art that are configured to operate in accordance with the techniques presented herein.

Generally, embodiments are described in the general context of “computer readable instructions” being executed by one or more computing devices. Computer readable instructions may be distributed via computer readable media as will be discussed below. Computer readable instructions may be implemented as program modules, such as functions, objects, Application Programming Interfaces (APIs), data structures, and the like, that perform one or more tasks or implement one or more abstract data types. Typically, the functionality of the computer readable instructions are combined or distributed as desired in various environments.

FIG. 8illustrates a system800that may include a computing device802configured to implement one or more embodiments provided herein. In one configuration, the computing device802may include at least one processing unit804and at least one memory806. Depending on the exact configuration and type of computing device, the at least one memory806may be volatile, such as RAM, nonvolatile, such as ROM, flash memory, etc., or a combination thereof. This configuration is illustrated inFIG. 8by dashed line808.

In other embodiments, the device802may include additional features or functionality. For example, the device802may include additional storage such as removable storage or non-removable storage, including, but not limited to, magnetic storage, optical storage, etc. Such additional storage is illustrated inFIG. 8by storage810. In one or more embodiments, computer readable instructions to implement one or more embodiments provided herein are in the storage810. The storage810may store other computer readable instructions to implement an operating system, an application program, etc. Computer readable instructions may be loaded in the at least one memory806for execution by the at least one processing unit804, for example.

Computing devices may include a variety of media, which may include computer-readable storage media or communications media, which two terms are used herein differently from one another as indicated below.

Computer-readable storage media may be any available storage media, which may be accessed by the computer and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer-readable storage media may be implemented in connection with any method or technology for storage of information such as computer-readable instructions, program modules, structured data, or unstructured data. Computer-readable storage media may include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or other tangible and/or non-transitory media which may be used to store desired information. Computer-readable storage media may be accessed by one or more local or remote computing devices (e.g., via access requests, queries or other data retrieval protocols) for a variety of operations with respect to the information stored by the medium.

The device802may include input device(s)812such as keyboard, mouse, pen, voice input device, touch input device, infrared cameras, video input devices, or any other input device. Output device(s)814such as one or more displays, speakers, printers, or any other output device may be included with the device802. The input device(s)812and the output device(s)814may be connected to the device802via a wired connection, wireless connection, or any combination thereof. In one or more embodiments, an input device or an output device from another computing device may be used as the input device(s)812and/or the output device(s)814for the device802. Further, the device802may include communication connection(s)816to facilitate communications with one or more other devices, illustrated as a computing device818coupled over a network820.

Various operations of embodiments are provided herein. The order in which one or more or all of the operations are described should not be construed as to imply that these operations are necessarily order dependent. Alternative ordering will be appreciated based on this description. Further, not all operations may necessarily be present in each embodiment provided herein.

Although the disclosure has been shown and described with respect to one or more implementations, equivalent alterations and modifications will occur based on a reading and understanding of this specification and the annexed drawings. The disclosure includes all such modifications and alterations and is limited only by the scope of the following claims.