Patent Description:
Non-authentic transactions or transactions having non-authentic or invalid data are known to occur within an electronic network. Conventionally, each entity involved in the electronic transaction may attempt to evaluate transaction authenticity based on the information the entity has available. Some parties may outsource authenticity detection to third party providers. However, the ability of any entity to determine whether a transaction is authentic may be limited.

US patent application <CIT> is further prior art.

Thus, there is a need in the art for improvements in authenticating an electronic transaction in a transaction network.

The following presents a simplified summary of one or more implementations of the present disclosure in order to provide a basic understanding of such implementations. This summary is not an extensive overview of all contemplated implementations, and is intended to neither identify key or critical elements of all implementations nor delineate the scope of any or all implementations. Its sole purpose is to present some concepts of one or more implementations of the present disclosure in a simplified form as a prelude to the more detailed description that is presented later.

One example implementation relates to a computer device. The computer device may include a memory to store data and instructions; at least one processor configured to communicate with the memory; an operating system in communication with the memory and the at least one processor, wherein the operating system is operable to: receive a transaction; access transaction contextual data for the transaction; apply one or more authentication decision rules to the transaction contextual data to determine initial authentication assessment information for the transaction; convert the initial authentication assessment information into a condensed authentication assessment indicator having an assessment value selected from a plurality of assessment values based on an assessment value definition; transmit the condensed authentication assessment indicator for the transaction; receive a transaction authentication decision based in part on the condensed authentication assessment indicator; and process or deny processing the transaction based on the transaction authentication decision.

Another example implementation relates to a method of securing electronic transactions in a computing network, comprising: receiving a transaction; accessing transaction contextual data for the transaction; applying one or more authentication decision rules to the transaction contextual data to determine initial authentication assessment information for the transaction; converting the initial authentication assessment information into a condensed authentication assessment indicator having an assessment value selected from a plurality of assessment values based on an assessment value definition; transmitting the condensed authentication assessment indicator for the transaction; receiving a transaction authentication decision based in part on the condensed authentication assessment indicator; and processing or denying the processing of the transaction based on the transaction authentication decision.

Another example implementation relates to a computer-readable medium comprising stored instructions executable by a processor to secure electronic transactions in a computing network, comprising instructions executable to: receive a transaction; access transaction contextual data for the transaction; apply one or more authentication decision rules to the transaction contextual data to determine initial authentication assessment information for the transaction; convert the initial authentication assessment information into a condensed authentication assessment indicator having an assessment value selected from a plurality of assessment values based on an assessment value definition; transmit the condensed authentication assessment indicator for the transaction; receive a transaction authentication decision based in part on the condensed authentication assessment indicator; and process or deny processing the transaction based on the transaction authentication decision.

Additional advantages and novel features relating to implementations of the present disclosure will be set forth in part in the description that follows, and in part will become more apparent to those skilled in the art upon examination of the following or upon learning by practice thereof.

In the drawings, where dashed lines may indicate optional components or actions:.

This disclosure relates to devices and methods for authenticating and/or securing an electronic transaction in an electronic transaction network. The devices and methods may provide improved real-time authentication of the electronic transaction. The devices and methods may share the transaction contextual data acquired by a first evaluating entity, which receives the electronic transaction, with a second evaluating entity, which ultimately approves the transaction, so that the second evaluating entity may increase efficiency in an ability to detect an invalid or non-authentic transaction and/or invalid or non-authentic transaction data. In an implementation, the transaction may include transaction data, while the transaction contextual data may be additional associated information available to the first evaluating entity, and not typically available to the second evaluating entity. As such, the sharing of the transaction contextual data acquired by a first evaluating entity allows the second evaluating entity to make a better evaluation of the transaction based on the additional information represented by the transaction contextual information from the first evaluating entity. As a result, the devices and methods of the present disclosure provide an increase in efficiency and/or accuracy in validating electronic transactions that are authentic while, at the same time, increasing an efficiency and/or accuracy in identifying invalid or non-authentic electronic transactions. For example, in an electronic transaction processing network that processes millions of electronic transactions per day, removing non-authentic transactions from the network, as described by the present disclosure, may provide dramatic gains in computer processing efficiency, in computer memory resource utilization, and in network communication resource utilization, among other technical gains, by eliminating the unnecessary processing of invalid or non-authentic transactions.

In an implementation, the transaction contextual data acquired by the first evaluating entity may be analyzed and used to generate initial authentication assessment information, which may be converted into a condensed authentication assessment indicator that is shared with the second evaluating entity. For example, the initial authentication assessment information may be inferred data attributes in response to applying one or more authenticity decision rules to the transaction contextual information. The initial authentication assessment information may include or may then be converted, according to one or more specific assessment value definitions, into the condensed authentication assessment indicator having an assessment variable value selected from a plurality of assessment variable values based on the corresponding assessment value definition. Moreover, the condensed authentication assessment indicator may incorporate a standard format, e.g., normalized variables and normalized variable values, in order for the initial authentication assessment information to be quantitative and have quantitative and consistent information and/or definitions that may be interpreted in the same way by all parties, namely the first evaluating entity that will share the initial authentication assessment information and the second evaluating entity that will accept and use the initial authentication assessment information that is shared.

In the implementation, the initial authentication assessment information may be used by the second evaluating entity to make a transaction decision by using the additional information (e.g., relative to the transaction data of the transaction, or other information about the transaction typically available to the second evaluating entity) represented by the initial authentication assessment information. Thus, the present disclosure may improve accuracy and efficiency in evaluating and approving transactions in an electronic network.

Referring now to <FIG>, illustrated is a schematic block diagram of an example system <NUM> for evaluating an electronic transaction for authenticity, e.g., in order to detect an invalid or non-authentic electronic transaction. For example, a transaction-initiating entity <NUM>, such as a user computer device, may generate an electronic transaction <NUM> with the first evaluating entity <NUM>, such as an entity computer device. For example, the electronic transaction <NUM> may include, but is not limited to, one or more sets of transaction data related to an exchange between the transaction-initiating entity <NUM> and the first evaluating entity <NUM>.

In processing the transaction <NUM>, the first evaluating entity <NUM> may collect transaction contextual data <NUM> such as, but not limited to, data or attributes different from the data of the of the payment instrument, product, device, Internet Protocol (IP) location, and/or device. The first evaluating entity <NUM> may use the transaction contextual data <NUM> to evaluate the likelihood of a transaction being non-authentic or including invalid data. When the evaluation returns a high likelihood of authenticity or validity, the first evaluating entity <NUM> submits the transaction <NUM> to the second evaluating entity for authorization For example, he first evaluating entity <NUM> may submit the transaction <NUM> through the system <NUM> via a transaction network processing entity <NUM> and a transaction network <NUM>. The transaction network processing entity <NUM> may manage or control the routing of the transaction <NUM> through the system <NUM> by choosing the transaction network <NUM>, in some cases from a plurality of different potential transaction networks, and/or based on the destination, e.g., the second evaluating entity <NUM>. An additional authentication evaluation is done by the second evaluating entity <NUM>, resulting in an authentication decision <NUM> by the second evaluating entity <NUM> to either authorize or decline the transaction <NUM> submitted by the first evaluating entity <NUM>. The authentication decision <NUM> of the second evaluating entity <NUM> is passed back through the transaction network <NUM> and the transaction network processing entity transaction network processing entity <NUM>, and ultimately is received by the first evaluating entity <NUM>.

Authenticity evaluations done post-first evaluating entity, at the second evaluating entity level, are based on a different data set than the evaluation done at the first evaluating entity level. For example, the different information may include information that only the second evaluating entity has access to, such as but not limited to a transaction history associated with the transaction-initiating entity <NUM> or a customer/user thereof, and/or an authentication history associated with the transaction-initiating entity <NUM> or a customer/user thereof.

To supplement this information at the second evaluating entity <NUM>, the devices and methods may share the transaction contextual data <NUM> acquired by the first evaluating entity <NUM> and/or the initial authentication assessment information <NUM> and/or the condensed authentication assessment indicator <NUM> for the transaction <NUM> with the second evaluating entity <NUM> so that the second evaluating entity <NUM> may increase efficiency in an ability to detect and block non-authentic or invalid transactions resulting in an increase in the approval of good (e.g., valid, authenticated) transactions. The transaction contextual data <NUM>, initial authentication assessment information <NUM>, and/or the condensed authentication assessment indicator <NUM> may allow the second evaluating entity <NUM> to make a better evaluation of the transaction <NUM> based on this additional information.

Sharing this additional transaction contextual data <NUM> and/or initial authentication assessment information <NUM> and/or the condensed authentication assessment indicator <NUM> may be achieved by establishing a secondary data channel <NUM> from the first evaluating entity <NUM> or first evaluating entity's authenticity solution provider to the second evaluating entity <NUM>; or establishing a data channel <NUM> from the first evaluating entity <NUM> or first evaluating entity's authenticity solution provider to a conduit or a trust knowledge broker which may be the same as or integrated with the transaction network processing entity <NUM> or transaction network <NUM>, which will then be delivered to the second evaluating entity <NUM> either in a secondary data channel <NUM> or the primary authorization data channel used by the transaction <NUM> and authentication decision <NUM>.

In one example implementation, the electronic transaction may be a purchase transaction by a customer with a merchant. For instance, in a non-limiting implementation, the transaction may be a card-not-present transaction with a merchant conducted via a website of the merchant. In this case, the transaction may be forwarded from the website to the merchant. In a purchase transaction, particularly a card-not-present online transaction, the merchant may collect transaction contextual data such as, but not limited to, attributes of the payment instrument (e.g., account number, expiration date, security code, address information), customer information (e.g., customer name associated with the payment instrument), product identification information, transaction-initiating device information (e.g., device identification information, device Internet Protocol (IP) address, device geographic location), customer/cardholder location information (e.g., home address), customer details (e.g., login identity, e-mail address, and/or telephone number), product details (e.g., product type, profit margin, and/or revocability), location (e.g., IP geolocation, device geolocation, and/or shipping address), device fingerprinting (e.g., operating system (OS) configuration, hardware configuration, browser or device configuration), and/or any other information related to or identifying the customer, the payment instrument, the goods/services involved in the transaction, and/or the computer devices involved in the transaction. The merchant may use the transaction contextual data to evaluate the likelihood of a transaction being authentic. When the merchant evaluation returns likelihood of authenticity above an authenticity threshold, the merchant submits the transaction to an issuing bank for authorization via, for example, a payment processor, such as an acquiring processor, and via a transaction network. The issuing bank is a bank associated with the payment instrument identified in the transaction contextual data. An additional authentication evaluation is done by the issuing bank, which may be combined with a determination of available credit and/or credit rating associated with the customer, etc., resulting in a decision by the issuing bank to either authorize or decline the transaction submission by the merchant. Authenticity evaluations done post-merchant, at the issuing bank level, are based on a different data set than the evaluation done at merchant level For example the issuing bank has access to the cardholder's purchase history and credit history but is not able to utilize the transaction contextual data a first evaluating entity collects. Further, the issuing bank may have access to the complete cardholder purchase and/or credit history, debt status, address of the card holder used for billing, and purchase pattern data, among others. The decision of the issuing bank is passed back through transaction network and/or acquiring processor to the merchant, who may then deny or accept the electronic transaction <NUM>.

Referring now to <FIG>, illustrated therein is an example graph <NUM> illustrating different data from a transaction. First evaluating entity data <NUM> may include the transaction contextual data <NUM> and/or initial authentication assessment information <NUM> and/or the condensed authentication assessment indicator <NUM> (<FIG>) acquired by the first evaluating entity <NUM> (<FIG>). Further examples of transaction contextual data <NUM> may include, but is not limited to, customer details (e.g., login identity, e-mail address, and/or telephone number), product details (e.g., product type, profit margin, and/or revocability), location (e.g., IP geolocation, device geolocation, and/or shipping address), and/or device fingerprinting (e.g., operating system (OS) configuration, hardware configuration, browser or device configuration). Second evaluating entity data <NUM> may include data the second evaluating entity <NUM> (<FIG>) may use when evaluating a transaction. For example, second evaluating entity data <NUM> may include, but is not limited to, initiating entity or user transaction and/or authentication history, transaction pattern, data relating to capability of validly completing the transaction, etc. The intersection data <NUM> of the first evaluating entity data <NUM> and the second evaluating entity data <NUM> may include, for example, the certain transaction detail data, and/or initiating entity or user transaction and/or authentication data.

Referring now to <FIG>, illustrated therein is an example computer device <NUM> for use by the first evaluating entity <NUM> to evaluate one or more transactions <NUM> received from customer purchasers <NUM> (<FIG>). Computer device <NUM> may access the transaction contextual data <NUM> and/or initial authentication assessment information <NUM> and/or the condensed authentication assessment indicator <NUM> and may generate initial authentication assessment information <NUM> for the transaction <NUM> using the transaction contextual data <NUM>. Computer device <NUM> may transmit the transaction contextual data <NUM> and/or initial authentication assessment information <NUM> and/or the condensed authentication assessment indicator <NUM> to one or more third parties, such as, but not limited to, transaction network processing entity <NUM> (<FIG>), transaction network <NUM> (<FIG>), and/or second evaluating entity <NUM> (<FIG>). As such, the transaction contextual data <NUM> and/or initial authentication assessment information <NUM> and/or the condensed authentication assessment indicator <NUM> may aid the second evaluating entity <NUM> in detecting and blocking non-authentic or invalid transactions <NUM>, resulting in an increase in the approval of good transactions <NUM>.

Computer device <NUM> may include any mobile or fixed computer device, which may be connectable to a network. Computer device <NUM> may be, for example, a computer device such as a desktop or laptop or tablet computer, an internet of things (IOT) device, a cellular telephone, a gaming device, a mixed reality or virtual reality device, a music device, a television, a navigation system, a camera, a personal digital assistant (PDA), or a handheld device, or any other computer device having wired and/or wireless connection capability with one or more other devices.

Computer device <NUM> may include an operating system <NUM> executed by processor <NUM> and/or memory <NUM>. Memory <NUM> of computer device <NUM> may be configured for storing data and/or computer-executable instructions defining and/or associated with operating system <NUM>, and processor <NUM> may execute such data and/or instructions to instantiate operating system <NUM>. An example of memory <NUM> can include, but is not limited to, a type of memory usable by a computer, such as random access memory (RAM), read only memory (ROM), tapes, magnetic discs, optical discs, volatile memory, non-volatile memory, and any combination thereof. An example of processor <NUM> can include, but is not limited to, any processor specially programmed as described herein, including a controller, microcontroller, application specific integrated circuit (ASIC), field programmable gate array (FPGA), system on chip (SoC), or other programmable logic or state machine.

Operating system <NUM> may include an authenticity evaluator component <NUM> that receives one or more transactions <NUM>. The transactions <NUM> may be, for example, but are not limited to, a credit card transaction. In a non-limiting implementation, the transactions <NUM> may be a card-not-present transaction with a merchant conducted via a website of the merchant.

Authenticity evaluator component <NUM> may access transaction contextual data <NUM> associated with the transactions <NUM>. Transaction contextual data <NUM> may include, but is not limited to, customer details (e.g., login identity, e-mail address, and/or telephone number), product details (e.g., product type, profit margin, and/or revocability), location (e.g., IP geolocation, device geolocation, and/or shipping address), and/or device fingerprinting (e.g., operating system (OS) configuration, hardware configuration, browser or device configuration). Authenticity evaluator component <NUM> may generate initial authentication assessment information <NUM> and/or the condensed authentication assessment indicator <NUM> from the transaction contextual data <NUM> associated with the transactions <NUM>.

Authenticity evaluator component <NUM> may transmit the transaction contextual data <NUM> and/or initial authentication assessment information <NUM> and/or the condensed authentication assessment indicator <NUM> to one or more of an transaction network processing entity <NUM>, a transaction network <NUM>, and/or an second evaluating entity <NUM>, so that the transaction contextual data <NUM> and/or initial authentication assessment information <NUM> and/or the condensed authentication assessment indicator <NUM> may be used by the second evaluating entity <NUM> to make a better evaluation of the transaction <NUM> based on the additional information.

Sharing this additional transaction contextual data <NUM> may be achieved by establishing a secondary data channel <NUM> from the first evaluating entity <NUM> or first evaluating entity's authenticity solution provider to the second evaluating entity <NUM>; or establishing a data channel from the <NUM> first evaluating entity or first evaluating entity's authenticity solution provider to a conduit or a trust knowledge broker which may be the same as or integrated with the transaction network processing entity <NUM> or transaction network <NUM>, which will then be deliver to the second evaluating entity <NUM> either in a secondary data channel or the primary authorization data channel.

Each of these methods may provide varied level of flexibility for the amount and format of data that may be transmitted. Where available, the transaction contextual data <NUM> may be transmitted in the original and/or raw form, such as, IP address and/or e-mail ID may be shared. Second evaluating entity <NUM> will then have to use this raw data as inputs into their assessment methodologies. However, there may be difficulties in sharing raw data attributes since raw data attributes poses risk on privacy and/or competitive data between first evaluating entities <NUM>; technical ability of the system may not support accepting and processing the additional raw attributes; and/or the channel used for transmitting may be constrained on amount and format of data.

To solve for such constrained environments, authenticity evaluator component <NUM> may generate initial authentication assessment information <NUM> and/or condensed authentication assessment indicator <NUM> to share from the first evaluating entity <NUM> to one or more of an transaction network processing entity <NUM>, a transaction network <NUM>, and/or an second evaluating entity <NUM>. The initial authentication assessment information <NUM> and/or the condensed authentication assessment indicator <NUM> may be inferred data attributes in response to applying one or more authenticity decision rules <NUM> to the transaction contextual data <NUM>.

Authenticity evaluator component <NUM> may apply one or more authenticity decision rules <NUM> to the transaction contextual data <NUM> to determine a level of authenticity for the transaction <NUM> relative to an authenticity threshold level <NUM>. The one or more authenticity decision rules <NUM> may include, for example, a trained machine learning model and/or a set of rules to determine a level of authenticity for the transaction <NUM> and/or to classify the transaction <NUM>. For example, the level of authenticity may be one of a low authenticity, a medium authenticity, or a high authenticity relative to the authenticity threshold level <NUM>. With machine learning models, the level of authenticity may be defined based on one or more condensed authentication assessment indicators <NUM> of the initial authentication assessment information <NUM>. The level of authenticity may be used to determine a transaction classification <NUM> to approve, challenge, or reject the transaction <NUM>.

The initial authentication assessment information <NUM> may include or be converted into the form of the condensed authentication assessment indicator <NUM> computed by the authenticity evaluator component <NUM> using the transaction contextual data <NUM>. The condensed authentication assessment indicator <NUM> may serve as a single condensed indicator of inferred inferences, such as country/location of the device of the transaction-initiating entity <NUM> in reference to the country/location of the transaction-initiating entity <NUM> as known to the second evaluating entity <NUM>, or both of the above, based on the transaction <NUM>.

Sharing the initial authentication assessment information <NUM> may pose a risk of causing inefficiency due to inconsistency. For example, if only a probability score (e.g., assessing a level of authenticity) from first evaluating entity's predictive model is shared, then the initial authentication assessment information <NUM> may not be insightful, as second evaluating entities <NUM> may need to have visibility on the calibration of the probability score to understand an accuracy of the score. Moreover, information provided may be less insightful to second evaluating entities <NUM> if various first evaluating entities <NUM> share a probability score, derived by various types of different models with varying levels of accuracy. Another risk may include a first evaluating entity sharing an additional confidence in any attribute of the initial authorization assessment information <NUM>, such as, low, medium or high assessed level of authenticity. Questions may be raised regarding 'how low is low' or vice versa and may relate to varying interpretations level by the second evaluating entities <NUM>.

As such, authenticity evaluator component <NUM> of a first evaluating entity <NUM> may perform a calibration process <NUM> on the initial authentication assessment information <NUM> for consistency. The authenticity level may be visible for all parties based on accumulated data. The calibration process <NUM> may make adjustments to minimize and/or remove errors in the authenticity level and/or any errors in the initial authentication assessment information <NUM>. During the calibration process <NUM>, authenticity evaluator component <NUM> may incorporate a standard format, e.g., normalized variables and normalized variable values, for the initial authentication assessment information <NUM> and/or the condensed authentication assessment indicator <NUM> in order for this data to be quantitative and have consistent definitions that may be interpreted in the same way by all parties, namely the first evaluating entity <NUM> who will share this information and the second evaluating entity <NUM> who will accept and use this information that is shared.

The standard format of the data for the first evaluating entity assessment information <NUM> and/or the condensed authentication assessment indicator <NUM> may depend on the channel being used to transmit the first evaluating entity assessment information <NUM> and/or an amount of data that may be supported for transmission in that channel. In addition, the standard format of the data for the first evaluating entity assessment information <NUM> and/or the condensed authentication assessment indicator <NUM> may depend on a time limit for authorizing the transaction. Where the scope allows for a binary signal to be transmitted, an overall trust indicator may be shared as the initial authentication assessment information <NUM> and/or the condensed authentication assessment indicator <NUM>. Where the scope allows to share a single indicator variable, an ordinal value representing the initial authentication assessment information <NUM> and/or the condensed authentication assessment indicator <NUM> of an authenticity level of the transaction <NUM> or a quantitative indicator of any other implicit variables or a combination of these can be shared.

Where the scope allows to share a single indicator variable and a description, in addition to the above stated idea for the indicator variable, additional descriptions can be used to share reasons for the authenticity assessment for the transaction <NUM> or additional contextual indicators may be included in the initial authentication assessment information <NUM>. The details in the description may be made free form to help with investigation and understanding or be made ordinal to use as additional data elements for evaluation by the second evaluating entity <NUM>.

Where the scope allows to share two indicator variables an ordinal value representing the overall assessment of authenticity for the transaction <NUM> may be used as one indicator and quantitative or ordinal variables of implicit attributes driving the overall assessment can be shared as the initial authentication assessment information <NUM> and/or the condensed authentication assessment indicator <NUM>.

Where the scope allows to share set of raw data variables not limiting to indicators or flags a standardization can be achieved to not transmit private or competitive data but still transmit actionable insight as the initial authentication assessment information <NUM> and/or the condensed authentication assessment indicator <NUM>. The standardization of the raw data may be achieved by aggregation and categorization of data elements.

Authenticity evaluator component <NUM> may transmit the initial authentication assessment information <NUM> and/or the condensed authentication assessment indicator <NUM> to one or more of an transaction network processing entity <NUM>, a transaction network <NUM>, and/or an issuing <NUM>, so that the first evaluating entity assessment information <NUM> may be used by the second evaluating entity <NUM> to make a better evaluation of the transaction <NUM> based on the additional information represented by the first evaluating entity assessment information <NUM> and/or the condensed authentication assessment indicator <NUM>.

The second evaluating entity <NUM> may utilize processor <NUM> and/or memory <NUM> and execute authenticity determiner <NUM> to make the authentication decision <NUM> to approve the transaction <NUM>, challenge the transaction <NUM>, or reject the transaction <NUM>. Authenticity evaluator component <NUM> may receive the authentication decision <NUM> from the second evaluating entity <NUM>.

Referring now to <FIG>, illustrated is an example chart <NUM> with a binary signal for the initial authentication assessment information <NUM> and/or the condensed authentication assessment indicator <NUM>. Where the scope allows for a binary signal to be transmitted, a single binary value (e.g., an authenticity assessment value or trust indicator or authenticity assessment value <NUM>) will be shared as the initial authentication assessment information <NUM> and/or the condensed authentication assessment indicator <NUM>. The insight shared in initial authentication assessment information <NUM> and/or the condensed authentication assessment indicator <NUM> may be at the granularity of overall trust indicator of the transaction <NUM> or an implicit corresponding authentication data category, also referred to as an authentication category variable <NUM>, which may be agreed upon as appropriate by all parties involved. Such parties include the first evaluating entity <NUM> who will share the initial authentication assessment information <NUM> and the second evaluating entity <NUM> who will accept and use the initial authentication assessment information <NUM> and/or the condensed authentication assessment indicator <NUM>. Each authorization data category or authentication category variable <NUM> may correspond to a different authorization factor that may be taken into account to predict an authenticity of the transaction <NUM>.

Chart <NUM> represents some representative examples of formats for each of these authentication category variables <NUM> to convey consistent and quantitative definitions in a binary format. For example, trust indicators or authenticity assessment values <NUM> may be associated with a specific authentication assessment category <NUM>, which may define an authentication factor (e.g., transaction assessment, device history, shipping location history, and/or transaction instrument on file) that may be taken into account to predict an authenticity of the transaction <NUM>. The trust indicators or authenticity assessment values <NUM> may define the initial authentication assessment information <NUM> and/or the condensed authentication assessment indicator <NUM> in a binary format (e.g., a "<NUM>" or a "<NUM>") for each authentication assessment category <NUM>.

For each trust indicator or authenticity assessment value <NUM> associated with each authentication assessment category <NUM>, there may be a corresponding standard value definition <NUM> and/or additional insight <NUM> that may be inferred from the trust indicator or authenticity assessment value <NUM> by the second evaluating entity <NUM>. The standard value definition <NUM> and/or additional insight <NUM> for may be referred to herein individually or jointly as the assessment category value definition. For example, for authentication assessment category <NUM> of "device history," and authenticity assessment value <NUM> of "<NUM>," the value definition <NUM> may be known as "device known from previous transaction," and the value insight <NUM> may be known as "known device with predicted/likely low risk of non-authentic transaction. " By having a standard value definition <NUM> and/or standard additional insight <NUM>, the initial authentication assessment information <NUM> and/or the condensed authentication assessment indicator <NUM> may be quantitative and have consistent meaning that may be interpreted in a same way by all parties. The parties herein include the first evaluating entity <NUM> which will share the initial authentication assessment information <NUM> and/or the condensed authentication assessment indicator <NUM>, and the second evaluating entity <NUM>, which will receive and use the initial authentication assessment information <NUM> and/or the condensed authentication assessment indicator <NUM>.

Referring now to <FIG>, an example chart <NUM> includes a selectable single authorization assessment indicator value <NUM> that may be used as or with the first evaluating entity assessment information <NUM> and/or the condensed authentication assessment indicator <NUM> (<FIG>). Where the scope allows to share a single indicator value <NUM>, an ordinal value representing the initial authentication assessment information <NUM> and/or the condensed authentication assessment indicator <NUM> of authenticity of the transaction <NUM> (<FIG>) and/or a quantitative indicator of any other implicit variables or a combination of these can be shared.

Chart <NUM> includes some representative examples of formats for two or more different, selectable single authentication assessment indicator values <NUM> for a number of different authentication categories <NUM> associated with the transaction <NUM>. In addition, chart <NUM> includes examples of different authentication assessment value definitions <NUM> and/or insights <NUM> (referred to herein individually or jointly as authentication assessment value definitions) associated with each selectable single authentication assessment indicator value <NUM>. As such, a selected single authentication assessment value <NUM> provided to the second evaluating entity <NUM> may convey consistent and quantitative definitions. As such, each selected single authentication assessment indicator value <NUM> may be interpreted similarly by the first evaluating entity <NUM> and the second evaluating entity <NUM>. The insights <NUM> may be used by the second evaluating entity <NUM> in determining the authentication decision <NUM> for the transaction <NUM>. For example, for a authentication category <NUM> of "location assessment," a value <NUM> of "<NUM>" may have a standard value definition <NUM> of "location/city where transaction originates is same as known city associated with the user," and the value insight <NUM> may convey information such as "local transaction, low risk. " As such, the value definition <NUM> and/or value insights <NUM> provided to the second evaluating entity <NUM> when receiving a value <NUM> of "<NUM>" for a location assessment category <NUM> may be known and easily understood based on consistent and quantitative definitions.

By having consistent and/or quantitative definitions, all parties, namely the first evaluating entity <NUM> who will share the initial authentication assessment information <NUM> and/or the condensed authentication assessment indicator <NUM>, and the second evaluating entity <NUM> who will receive and use the initial authentication assessment information <NUM> and/or the condensed authentication assessment indicator <NUM> that is shared, may interpret the information in the same manner.

Referring now to <FIG>, an example method <NUM> may be used by a computer device <NUM> (<FIG>) of a first evaluating entity <NUM> (<FIG>) for in-line transaction assessments and/or sharing transaction contextual data. The actions of method <NUM> may be discussed below with reference to the architecture of <FIG>.

At <NUM>, method <NUM> may include receiving at least one transaction. Computer device <NUM> may include an authenticity evaluator component <NUM> that receives one or more transactions <NUM>, as described above.

At <NUM>, method <NUM> may include accessing transaction contextual data for the at least one transaction. Authenticity evaluator component <NUM> may access transaction contextual data <NUM> associated with the transactions <NUM>, as described above.

At <NUM>, method <NUM> may include applying one or more authenticity decision rules to the transaction contextual data to generate initial authentication assessment information. Authenticity evaluator component <NUM> may apply one or more authenticity decision rules <NUM> to the transaction contextual data <NUM> to determine the initial authentication assessment information <NUM>, which may indicate a level of authenticity for the transaction <NUM> relative to an authenticity threshold level <NUM>. The one or more authenticity decision rules <NUM> may include, for example, a trained machine learning model and/or a set of rules to determine a level of authenticity for the transaction <NUM> and/or classify the transaction <NUM>. The level of authenticity may be used to determine a transaction classification <NUM> to approve, challenge, or reject the transaction <NUM>.

For example, the level of authenticity may be one of a low authenticity, a medium authenticity, or a high authenticity relative to the authenticity threshold level <NUM>. With machine learning models, the level of authenticity may be defined based on the scores <NUM>. With rules, first evaluating entity can classify transactions <NUM> into multiple levels of authenticity segments based on predetermined authenticity decision rules <NUM> and the corresponding initial authentication assessment information <NUM>. For example, transactions <NUM> from some geolocations, using certain devices may have an assessed high authenticity level; from other geolocations, and with other certain devices may have a medium or a low assessed authenticity level.

The initial authentication assessment information <NUM> may include the level of authenticity for the transaction <NUM>. The initial authentication assessment information <NUM> may also include the transaction classification <NUM>. As such, the initial authentication assessment information <NUM> may be inferred data attributes in response to applying one or more authenticity decision rules <NUM>.

At <NUM>, method <NUM> may include converting the initial authentication assessment information into a condensed authentication assessment indicator having an assessment value selected from a plurality of assessment values based on an assessment value definition. For example, in an aspect, authenticity evaluator component <NUM> is configured to converting the initial authentication assessment information into a condensed authentication assessment indicator having an assessment value selected from a plurality of assessment values based on an assessment value definition, as described above.

For example, the initial authentication assessment information <NUM> may include or may be converted into the form of the condensed authentication indicator <NUM> computed by the authenticity evaluator component <NUM> using the transaction contextual data <NUM>. The condensed authentication indicator <NUM> may serve as a single condensed indicator. Example condensed authentication indicators <NUM> may include, but are not limited to, indicators <NUM> (<FIG>) and/or indicators <NUM>.

Authenticity evaluator component <NUM> may incorporate a standard format e.g., normalized variables and normalized variable values, associated with the condensed authentication indicator <NUM> in order for the condensed authentication indicator <NUM> to be quantitative and have consistent definitions that may be interpreted in the same way by all parties involved in evaluating the transaction <NUM>.

The standard format of the data for the condensed authentication indicator <NUM> may depend on the channel being used to transmit the condensed authentication indicator <NUM> and/or an amount of data that may be supported for transmission in that channel. For example, one second evaluating entity <NUM> or transaction network <NUM> may support a binary signal, while another second evaluating entity <NUM> or transaction network <NUM> may support five words. Another example may include a second evaluating entity <NUM> that supports one word and a transaction network processing entity <NUM> supports a binary signal. As such, different channels may support different formats for the condensed authentication indicator <NUM>. In addition, the standard format of the data for the condensed authentication indicator <NUM> may depend on a time limit for authorizing the transaction.

Where the scope allows for a binary signal to be transmitted, an overall authentication trust indicator may be shared as the condensed authentication indicator <NUM>. Where the scope allows to share a single indicator variable, the condensed authentication indicator <NUM> may be an ordinal value representing an authenticity level of the transaction <NUM> or a quantitative indicator of any other implicit variables or a combination of these can be shared.

In some implementations, the assessment value corresponds to an authentication category variable of a plurality of authentication category variables associated with the transaction, wherein the authentication category variable and the assessment value identify an initial assessed level of authenticity of the transaction.

In some implementations, the condensed authentication assessment indicator comprises a plurality of different assessment category values associated with a plurality of different authentication category variables, wherein each of the plurality of different authentication category variables correspond to a different one of a plurality of authenticity assessment factors, and wherein each of the plurality of different assessment category values is based on a different one of a plurality of different assessment category value definitions.

In some implementations, the plurality of authenticity assessment factors are selected from a group consisting of a transaction assessment factor, a device history assessment factor, a location assessment factor, a transaction data assessment factor, and a combined factor assessment factor.

At <NUM>, method <NUM> may include transmitting the condensed authentication assessment information. Authenticity evaluator component <NUM> may transmit the condensed authentication indicator <NUM> to one or more of an transaction network processing entity <NUM>, a transaction network <NUM>, and/or an second evaluating entity <NUM>, so that the condensed authentication indicator <NUM> may be used by the second evaluating entity <NUM> to make a better evaluation of the transaction <NUM> based on the additional information represented by the condensed authentication indicator <NUM>.

For example, authenticity evaluator component <NUM> may establish a secondary data channel <NUM> from the first evaluating entity <NUM> or first evaluating entity's authenticity solution provider to the second evaluating entity <NUM>; or establish a data channel from the first evaluating entity or first evaluating entity's authenticity solution provider to a conduit or a trust knowledge broker which may be the same as or integrated with the transaction network processing entity <NUM> or transaction network <NUM>, which will then be delivered to the second evaluating entity <NUM> either in a secondary data channel or the primary authorization data channel.

At <NUM>, method <NUM> may include receiving a transaction authentication decision based in part on the condensed authentication assessment information. The second evaluating entity <NUM> may make a transaction authorization decision <NUM> to approve the transaction <NUM>, challenge the transaction <NUM>, or reject the transaction <NUM>. Authenticity evaluator component <NUM> may receive the transaction authorization decision <NUM> from the second evaluating entity <NUM>.

At <NUM>, method <NUM> may include processing or denying processing the transaction based on the transaction authentication decision. For example, in an aspect, authenticity evaluator component <NUM> may be configured to process or deny processing the transaction <NUM> based on the transaction authentication decision <NUM>, as described above.

Optionally, at <NUM>, method <NUM> may include storing the transaction contextual data, the initial authorization assessment information, the condensed authentication assessment indicator, and/or the transaction authorization decision. Authenticity evaluator component <NUM> may store the received transaction authorization decision <NUM>, the initial authentication assessment information <NUM>, the condensed authentication assessment indicator <NUM>, and/or the transaction contextual data <NUM> for the transaction <NUM>. The stored information may be used for future modeling and/or training the machine learning model for improving the accuracy of the condensed authentication assessment indicator.

As such, method <NUM> may be used by the second evaluating entity <NUM> to make a better evaluation of the transaction <NUM> based on the additional information represented by the transaction contextual data, the initial authorization assessment information, and/or the condensed authentication assessment indicator.

Referring now to <FIG>, an example process <NUM> of building machine learning models and/or setting decision rules may be used for determining different levels of risk or authenticity <NUM>, <NUM>, <NUM> in graph <NUM>. The process of building machine learning models and/or setting decision rules <NUM> may occur offline by, for example, computer device <NUM> (<FIG>) or any other computer device.

First evaluating entities may use stored transaction data (authenticity label, and other features associated with historical transactions and/or historical transaction data) or forecasting data to train machine learning models and/or to set risk or authenticity decision rules <NUM>. The machine learning model training and/or setting risk or authenticity decision rules <NUM> may use part of the historical transactions data stored in a database of first evaluating entities database to forecast eventual authenticity rates to periodically train machine learning models and/or to set decision rules for assessing authenticity of new coming transactions. For example, transactions originating from some certain geolocation with certain devices may be considered to have a low authenticity level based on historical observation. There may be latency in receiving completed and/or true authenticity labels from second evaluating entity <NUM> for some historical transactions. As such, the machine learning model training and/or setting the authenticity decision rules <NUM> may use partially obtained authenticity labels to forecast complete authenticity volume for each score bin.

The historical transactions data used by the machine learning model training and/or setting the authenticity decision rules <NUM> may include historical transactions with associated original (raw) features, such as, product type, purchase amount, geolocation, etc., and aggregated features, such as, account, device, location, distance, etc. The historical transactions data may also include forecasting data (using historical data), associated authenticity decisions, machine learning generated scores, and/or a true authenticity label (e.g., authentic or not-authentic).

Based on either machine leaning model and/or setting the authenticity decision rules <NUM>, first evaluating entities can have three or more levels of authenticity <NUM>, <NUM>, <NUM>, or rates of non-authenticity, defined (i.e., high authenticity or low risk/low non-authenticity rate, medium authenticity or medium risk/medium non-authenticity rate, low authenticity or high risk/high non-authenticity rate) for all the incoming transactions. With machine learning models, the level of authenticity may be defined based on the scores <NUM> (<FIG>) of the initial authentication assessment information <NUM> (<FIG>).

With rules, first evaluating entity can classify transactions <NUM> into three or more levels of authenticity <NUM>, <NUM>, <NUM> based on predetermined authenticity decision rules <NUM> (<FIG>). For example, system may be adjust the non-authenticity rates to define different segments or zones each having a target level of risk and/or rate of non-authenticity. For example, a first segment may be defined to have the total non-authentic rate of < <NUM>%. A second segment/zone may be set to have the total non-authentic rate being > <NUM>% and < <NUM> %, while a third zone/segment may be set of have a non-authenticity rate of > <NUM>%, resulting in the three levels of authenticity <NUM>, <NUM>, <NUM> being determined.

For example, transactions <NUM> originating from some geolocations, using certain devices may be associated with high authenticity (or low non-authenticity rates) and hence low risk, e.g., the first segment/zone <NUM>; while transactions <NUM> originating from other geolocations, and with other certain devices are associated with medium authenticity (or medium non-authenticity rates) and hence medium risk, e.g., second segment/zone <NUM>, or low authenticity (or high non-authenticity rates) and hence high risk, e.g., third segment/zone <NUM>. The boundaries of each segment/zone may be adjustable and may be set based on the predicted non-authenticity rates determined using the machine learning generated score or rules.

Referring now to <FIG> an example computer <NUM> that may be configured as computer device <NUM> in accordance with an implementation includes additional component details as compared to <FIG>. In one example, computer <NUM> may include processor <NUM> for carrying out processing functions associated with one or more of components and functions described herein. Processor <NUM> can include a single or multiple set of processors or multicore processors. Moreover, processor <NUM> can be implemented as an integrated processing system and/or a distributed processing system.

Computer <NUM> may further include memory <NUM>, such as for storing local versions of applications being executed by processor <NUM>. Memory <NUM> can include a type of memory usable by a computer, such as random access memory (RAM), read only memory (ROM), tapes, magnetic discs, optical discs, volatile memory, non-volatile memory, and any combination thereof. Additionally, processor <NUM> may include and execute operating system <NUM> (<FIG>).

Further, computer <NUM> may include a communications component <NUM> that provides for establishing and maintaining communications with one or more parties utilizing hardware, software, and services as described herein. Communications component <NUM> may carry communications between components on computer device <NUM>, as well as between computer device <NUM> and external devices, such as devices located across a communications network and/or devices serially or locally connected to computer device <NUM>. For example, communications component <NUM> may include one or more buses, and may further include transmit chain components and receive chain components associated with a transmitter and receiver, respectively, operable for interfacing with external devices.

Additionally, computer <NUM> may include a data store <NUM>, which can be any suitable combination of hardware and/or software, that provides for mass storage of information, databases, and programs employed in connection with implementations described herein. For example, data store <NUM> may be a data repository for authenticity evaluator component <NUM>.

Computer <NUM> may also include a user interface component <NUM> operable to receive inputs from a user of computer device <NUM> and further operable to generate outputs for presentation to the user. User interface component <NUM> may include one or more input devices, including but not limited to a keyboard, a number pad, a mouse, display (e.g., which may be a touch-sensitive display), a navigation key, a function key, a microphone, a voice recognition component, any other mechanism capable of receiving an input from a user, or any combination thereof. Further, user interface component <NUM> may include one or more output devices, including but not limited to a display, a speaker, a haptic feedback mechanism, a printer, any other mechanism capable of presenting an output to a user, or any combination thereof.

In an implementation, user interface component <NUM> may transmit and/or receive messages corresponding to the operation of authenticity evaluator component <NUM>. In addition, processor <NUM> executes authenticity evaluator component <NUM>, and memory <NUM> or data store <NUM> may store it.

As used in this application, the terms "component," "system" and the like are intended to include a computer-related entity, such as but not limited to hardware, firmware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a computer device and the computer device can be a component. One or more components can reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers. In addition, these components can execute from various computer readable media having various data structures stored thereon. The components may communicate by way of local and/or remote processes such as in accordance with a signal having one or more data packets, such as data from one component interacting with another component in a local system, distributed system, and/or across a network such as the Internet with other systems by way of the signal.

Various implementations or features may have been presented in terms of systems that may include a number of devices, components, modules, and the like. It is to be understood and appreciated that the various systems may include additional devices, components, modules, etc. and/or may not include all of the devices, components, modules etc. discussed in connection with the figures. A combination of these approaches may also be used.

The various illustrative logics, logical blocks, and actions of methods described in connection with the embodiments disclosed herein may be implemented or performed with a specially-programmed one of a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A processor may also be implemented as a combination of computer devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Additionally, at least one processor may comprise one or more components operable to perform one or more of the steps and/or actions described above.

Further, the steps and/or actions of a method or algorithm described in connection with the implementations disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium may be coupled to the processor, such that the processor can read information from, and write information to, the storage medium. Further, in some implementations, the processor and the storage medium may reside in an ASIC. Additionally, the ASIC may reside in a user terminal. Additionally, in some implementations, the steps and/or actions of a method or algorithm may reside as one or any combination or set of codes and/or instructions on a machine readable medium and/or computer readable medium, which may be incorporated into a computer program product.

In one or more implementations, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored or transmitted as one or more instructions or code on a computer-readable medium. A storage medium may be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc where disks usually reproduce data magnetically, while discs usually reproduce data optically with lasers.

Claim 1:
A computer device for securing electronic transactions in a computing network, comprising:
a memory to store data and instructions;
at least one processor configured to communicate with the memory;
an operating system in communication with the memory and the at least one processor,
wherein the operating system is operable to:
receive a transaction;
access transaction contextual data for the transaction;
apply one or more authentication decision rules to the transaction contextual data to determine initial authentication assessment information for the transaction;
convert the initial authentication assessment information into a condensed authentication assessment indicator having an assessment value selected from a plurality of assessment values based on an assessment value definition;
transmit the condensed authentication assessment indicator for the transaction;
receive a transaction authentication decision based in part on the condensed authentication assessment indicator; and
process or deny processing the transaction based on the transaction authentication decision;
wherein the condensed authentication assessment indicator incorporates a standard format, in order for the initial authentication assessment information to be quantitative and have quantitative and consistent information and/or definitions that can be interpreted in the same way by all parties.