C Conditions Reference

This appendix provides information about the conditions available standard on Oracle Adaptive Access Manager.

• Autolearning Conditions

  • Pattern (Authentication): Entity is Member of Pattern Bucket for First Time in Certain Time Period

  • Pattern (Authentication): Entity is Member of Pattern Less Than Some Percent Time

  • Pattern (Authentication): Entity is Member of Pattern Less Than Some Percent with All Entities in Picture

  • Pattern (Authentication): Entity is Member of Pattern N Times

  • Pattern (Authentication): Entity is Member of Pattern N Times in a Given Time Period

• Device Conditions

  • Device: Browser Header Substring

  • Device: Check if Device is of Given Type

  • Device: Device First Time for User

  • Device: Excessive Use

  • Device: In Group

  • Device: Is Registered

  • Device: Timed Not Status

  • Device: Used Count for User

  • Device: User Count

  • Device: User Status Count

  • Device: Velocity from Last Successful Login

• Location Conditions

  • Location: ASN in Group

  • Location: in City Group

  • Location: In Carrier Group

  • Location: In Country Group

  • Location: IP Connection Type in Group

  • Location: IP in Range Group

  • Location: IP Line Speed Type

  • Location: IP Maximum Users

  • Location: IP Routing Type in Group

  • Location: Is IP from AOL

• Session Conditions

  • Session: Check Param Value

  • Session: Check Param Value in Group

  • Session: Check Param Value for Regex

  • Session: Check two string param value

  • Session: Check String Value

  • Session: Time Unit Condition

  • Session: Compare Two Parameter Values

  • Session: Check Current Session Using the Filter Conditions

  • Session: Check Risk Score Classification

  • Session: Cookie Mismatch

  • Session: Mismatch in Browser Fingerprint

  • Session: Compare with Current Date Time

  • Session: IP Changed

  • Session: Check value in comma separated values

• System Conditions

  • System - Check Boolean Property

  • System - Check Enough Pattern Data

  • System - Check If Enough Data is Available for Any Pattern

  • System - Check Int Property

  • System - Check Request Date

  • System - Check String Property

• Transactions Conditions

  • Transaction: Check Count of Any Entity or Element of a Transaction Using Filter Conditions

  • Transaction: Check Current Transaction Using Filter Condition

  • Transaction: Check if Consecutive Transactions in Given Duration Satisfy the Filter Conditions

  • Transaction: Check Number of Times Entity Used in Transaction.

  • Transaction: Check Transaction Aggregrate and Count Using Filter Conditions

  • Transaction: Check Transaction Count Using Filter Condition

  • Transaction: Compare Transaction Aggregrates (Sum/Avg/Min/Max) Across Two Different Durations

  • Transaction: Compare Transaction Counts Across Two Different Durations

  • Transaction: Compare Transaction Entity/Element Counts Across Two Different Durations

  • Transaction: Check Unique Transaction Entity Count with the specified count

• User Conditions

  • User: Check If Devices Of Certain Type Are Used

  • User: Check User Data

  • User: Stale Session

  • User: Devices Used

  • User: Velocity from Last Success

  • Understanding How the OAAM Device Max Velocity Rule Settings Work

  • User: Check Number of Registered Devices Of Given Type

C.1 List of Available Conditions

The following table lists the available out of the box conditions.

Table C-1 Rule Conditions

Condition	Description
Always On - User	This rule always gets processed
Device: Browser header substring	Checks whether the supplied string exists as a substring in the browsers header information
Device: Check if device is of given type	Checks whether the current device is of selected device type.
Device: Check if device is using Mobile Browser	Checks whether the current device is using mobile browser to access the site based on the User Agent String
Device: Device first time for user	Checks whether this device is used for the first time by this user
Device: Device in group	Checks if this device is in group
Device: Excessive use	Checks whether device is excessively used but not used before
Device: Is registered	Checks if the user has registered this device
Device: Timed not status	Checks the maximum login attempts for all but the given status within the given time period
Device: User count	Checks the unique user count using this device in past "x" seconds
Device: Used count for User	Checks the device used count. This condition ignores the current request for calculating the device count.
Device: User status count	Checks the user count with the given status from this device in specified duration
Device: Velocity from last login	Triggers when miles per hour is more than specified value and the IP does not belong to ignore IP group
Location: ASN in group	Checks whether the ASN for the current IP address is (or is not) in the ASN group
Location: Carrier in group	Checks if the IP is in the given carrier group
Location: City in group	Checks if the IP is in the given city group
Location: Domain in group	Checks if the Second Level Domain is in the group
Location: In Country group	Checks if the IP is in the given country group
Location: IP Connection speed in group	Checks if the IP Connection Speed is in the group
Location: IP Connection type	Checks the connection type for the IP. The connection type could be DSL, Cable, ISDN, Dialup, Fixed Wireless, Mobile Wireless, Satellite, Frame Relay, T1/T3, OCx, and others
Location: IP Connection type in group	Checks if the IP connection type is in the group
Location: IP Excessive use	Checks if IP is excessively used but not used before
Location: IP in group	Checks if the IP is in the IP group
Location: IP in Range group	Checks if the IP is in the IP range specified in an IP Range group. Condition will check if IP of activity belongs to one of the IP ranges specified in the list of ranges.
Location: IP is AOL	Checks if the IP is from an AOL proxy
Location: IP line speed type	Checks the connection line speed type for the IP. This is categorized into High, Medium, Low or Unknown
Location: IP Maximum logins	Checks the maximum number of logins using the current IP address within the given time duration. This condition ignores the current request during evaluation of maximum logins count.
Location: IP Maximum Users	Checks the maximum number of users using the current IP address within the given time duration
Location: IP Multiple Devices	Checks the maximum number of devices from IP address within the given time duration
Location: IP routing type	Checks the routing type for the IP. It could be fixed/static, anonymizer, AOL, POP, Super POP, Satellite, Cache Proxy, International Proxy, Regional Proxy, Mobile Gateway or Unknown
Location: IP Routing Type in group	Checks if the IP Routing Type is in the group
Location: IP type	Checks if IP is valid, unknown or private
Location: Is IP from AOL	Checks if the IP is from AOL proxy
Location: ISP in group	Checks if the ISP for the current IP address is (or is not) in the ISP group
Location: State in group	Checks if the IP is in the given State group
Location: Timed not status	Checks the maximum login attempts for all but the given status within the given time period
Location: Top Level Domain in group	Checks if the Top Level Domain is in the group
Location: User status count	Check the user count with the given status from this location in specified duration
Pattern (Authentication): Entity is a member of the pattern less than some percent of time	Evaluates if the entity of the type specified (user, device, location, and so on) involved in the current access request has been a member of the pattern specified less/more than the defined percentage within the time range configured.
Pattern (Authentication): Entity is a member of pattern bucket for the first time in a certain time period	Checks if this Entity is member of pattern bucket for first time in certain time period
Pattern (Authentication): Entity is a member of the pattern bucket less than some percent with all entities in the picture	Checks if this entity has been member of this pattern bucket based on percent basis, taking into account all other entities
Pattern (Authentication): Entity is a member of the pattern N times	Checks to determine whether the entity is a member of the pattern more than "n" number of times. This condition is intended to be used only with single bucket type patterns since it evaluates pattern membership as opposed to individual bucket membership.
Pattern (Authentication): Entity is a member of the pattern N times in a given time period	Checks if this entity has been member of this bucket. You can compare if this entity has been belonging to this bucket before.
Transaction: Check Count of any entity or element of a Transaction using filter conditions	Checks count of any entity or element of a Transaction using filter conditions
Transaction: Check Current Transaction using the filter conditions	Checks current transaction using filter conditions
Transaction: Check if consecutive Transactions in given duration satisfy the filter conditions	Check if consecutive transactions in given duration satisfy the filter conditions
Transaction: Check number of times entity used in transaction.	Compares the number of times an entity used has been used with the specified count.
Transaction: Check Transaction Aggregrate and Count using filter conditions	Checks the transaction aggregrate and count using filter conditions
Transaction: Check Transaction Count using filter conditions	Checks the transaction count using filter conditions
Transaction: Check Unique Transaction Entity Count with the specified count	Checks the unique transaction entity count with the specified count
Transaction: Compare Transaction Aggregrates (Sum/Avg/Min/Max) across two different durations	Compares the transaction aggregrates (Sum/Avg/Min/Max) across two different durations
Transaction: Compare Transaction Counts across two different durations	Compares the transaction counts across two different durations
Transaction: Compare Transaction Entity or Element Counts across two different durations	Compares the transaction entity or element counts across two different durations
Session: Check parameter value	Checks if specified parameter value is more than specified value
Session: Check parameter value for regular expression	Checks if specified parameter value matches regular expression
Session: Check parameter value in group	Checks if specified parameter value is in group
Session: Check Risk Score Classification	Checks the risk score classification based on the risk score from previous checkpoint execution
Session: Check string parameter value	Checks to compare string value
Session: Check two string parameter value	Checks to compare two parameters string value
Session: Check value in comma separated values	Checks if specified value is present in comma separated value list.
Session: Compare two parameter values	Compares two parameter values
Session: Check enough pattern data	Checks if enough pattern data is available for given pattern
Session: Check enough any pattern data	Checks if enough pattern data is available in the system for any pattern
Session: Check Current Session using the filter conditions	Check Current Session using (up to 5) filter conditions
Session: Compare with current date time	Compares specified parameter value with current time
Session: Cookie Mismatch	Checks to see if there is mismatch of supplied cookie with the expected cookie
Session: IP Changed	Checks if IP Address is changed since transaction is started
Session: Mismatch in Browser Fingerprint	Checks to see if there is mismatch in browser fingerprint with the fingerprint supplied during authentication. Fingerprint is constructed using the context values passed to Rules Engine
Session: Time Unit	Checks if the current time unit matches the specified time unit criteria.
System - Check Boolean Property	Checks the system property
System: Check if enough data is available for any pattern	Checks if a defined minimum amount of pattern data has been captured in the OAAM database. Generally the threshold should be set to between 1-3 months for best results. The out of the box policies utilize this rule to determine if there is enough pattern data captured to start running pattern based risk analysis.
System: Check if enough pattern data is available	Checks if enough pattern data is available. This condition will check if pattern data is available in the system for last several days for a given pattern.
System - Check Integer Property	Checks system property
System - Check Policy max score	Checks Policy maximum score
System - Check Policy min Score	Checks Policy minimum score
System - Check Request Date	Checks request date
System - Check String Property	Checks system property
System - Evaluate Policy	Processes the policy as rule and evaluate results
User: Account Status	Checks account status of the user
User: Action Count	Checks action counter for the given action. This condition has dependency on action configuration
User: Action Count Timed	Checks if the given action count is more than specified count. If checkpoint is not specified, action is checked in all checkpoints
User: Action Timed	Checks maximum number of actions in the past "x" seconds
User: ASN for first time	Checks if user using this ASN for the first time?
User: Authentication Image Assigned	Checks if authentication image is assigned to user
User: Authentication Mode	Check user authentication mode
User: Challenge Channel Failure	Checks if a user has a failure counter value over a specified value from specific channel
User: Challenge Failure Is Last Challenge Before	Checks if it is the last challenge before number of hours, since number of days have passed.
User: Challenge Failure - Minimum Failures	Checks if a user has a failure counter value over a specified value.
User: Challenge Maximum Failures	Checks if user failed to answer challenge question for specified number of times
User: Challenge Questions Failure	Checks how many questions have failures
User: Challenge timed	Checks if user answered challenge question successfully in last n days
User: Check Anomalous User Request	Checks if the current User Request is Anomalous
USER: Check Devices of Certain Type are Used	Checks if devices of certain type are used for successful sessions within some seconds
User: Check Devices Used	Checks the number of devices tried in given time
User: Check first login time	Checks if user first logged in within range. First login is the first successful login
User: Check Fraudulent User Request	Checks if the current User Request is fraudulent
User: Check Information	Checks to see if user information is set. Information data to check is sent as key value pair.
User: Check Last Session Action	Checks if the given action is in last session. If checkpoint is not specified, action is checked in all checkpoints of that session
User: Check login count	Checks user login count within specified duration
User: Check Login Time	Checks if user login time is within the specified time
User: Check OTP Failures	Checks if user's OTP failure counter value over a specified value
User: Check User Data	Checks User Data for the given key
User: Checkpoint score	Checks if the score is within limits
User: City first time for user	Checks whether the user is using this city for the first time?
User: Client And Status	Checks account status of the user
User: Country failure count for user	Checks failure count for the user from the given country
User: Country first time for user	Checks if the user is using this Country for the first time?
User: Country first time from group	Checks if this country is used for the first time by this user from the given country group
User: Distance from last successful login	Checks the distance from last successful login within specified time
User: Distance from last successful login within limits	Checks if distance from last successful login within specified time is within limits
User: Image Status	Checks the image status of the user
User: In Group	Checks if the user is in the given group
User: IP carrier for first time	Checks if the user is using this IP carrier for the first time?
User: Is last IP match with current IP	Checks if user login IP address matches with that of previous login
User: Is User Agent Match	Checks if user agent matches with that of previous login from same device
User: Last Login Status	Checks to see if user login status is in specified list
User: Last login within specified time	Checks the last login within specified time
User: Location Used Timed	Checks if user used this location within the given time period
User: Login for first time	Checks if user is logging in for the first time
User: Login in group	Checks if the user login is in the given group
User: Login time between specified times	Checks the login time between specified time
User: Maximum Cities	Checks the number of cities within the given time period
User: Maximum Countries	Checks the number of countries within the given time period
User: Maximum IPs Timed	Checks the maximum number of IP within the given time period
User: Maximum Locations Timed	Checks the maximum number of locations within the given time period
User: Maximum States	Checks the number of states within the given time period
User: Multiple failures	Checks if user failed multiple times
User: Check Number of Registered Devices Of Given Type	Number of registered devices of given type.
User: Phrase Status	Checks phrase status of the user
User: Preferences Configured	Checks if the user preferences are set
User: Question Status	Checks Question status of the user
User: Stale session	Checks if a newer session was established after this session is created
User: State first time for user	Checks if the user is using this state for the first time?
User: Status Count Timed	Checks if user attempted multiple logins in specified time
User: User Agent Percentage Match	Checks if user agent percentage match is above specified percentage. Compares with browser user agent string (UAS) of previous login from same device
User: User Carrier for first time	Checks to see if the user has used this Carrier successfully previously
User: User City for first time	Checks to see if the user has used this City successfully previously
User: User Country for first time	Checks to see if the user has used this Country successfully previously
User: User Group in Group	Checks if the user group is in the given group
User: User IP for first time	Checks if the user has used this IP successfully previously
User: User ISP for first time	Checks if the user has used this ISP successfully previously
User: User is member of pattern N times	Checks if this user has been member of this pattern Condition
User: User state for first time	Checks if the user has used this state successfully previously
User: Velocity from last successful login	Checks the velocity from last successful login
User: Velocity from last successful login within limits	Triggers when velocity from last successful login is within specified limits

The following table lists the device fingerprinting policies.

Table C-2 Device ID Policies

Condition	Description
Device ID: Cookies match	Checks if tracker node matches for both cookies
Device ID: Cookie state	Checks the cookie state for the given device and user
Device ID: Header data match	Checks if header data match
Device ID: Header data match percentage	Checks if header data match percentage is within specified range
Device ID: Header data present	Checks if header data is present
Device ID: HTTP header data browser match	Checks if browser is matched based on HTTP header data
Device ID: HTTP header data browser upgrade	Checks if browser is upgraded based on HTTP header data
Device ID: HTTP header data OS match	Checks if OS match based on HTTP header data
Device ID: HTTP header data OS upgrade	Checks if OS is upgraded based on HTTP header data. Check is based on versions
Device ID: Is cookie disabled	Checks if cookie is disabled for the user based on history
Device ID: Is cookie empty	Checks if cookie value is empty or not empty. Validation check is not included
Device ID: Is Cookie from same device	Checks if the HTTP and flash cookies are from same device. Automatically checks old nodes, if current node is not found
Device ID: Is Cookie Old	Checks if the cookie sent is from old cookie
Device ID: Is cookie valid	Checks if there is a valid node for given cookie value
Device ID: known header data match percentage	Checks if known header data match percentage is within specified range
Device ID: User ASN for first time	Checks if the user has used this ASN successfully previously
Device ID: User used this fingerprint	Checks if the user has used this fingerprint previously

C.2 Descriptions

This chapter focuses on device, autolearning, location, transaction, session, system, and user conditions.

The appendix is organized as follows:

• Autolearning Conditions

• Device Conditions

• Session Conditions

• Location Conditions

• System Conditions

• Transactions Conditions

• User Conditions

C.2.1 Autolearning Conditions

The section provides information on the following autolearning conditions:

• Pattern (Authentication): Entity is Member of Pattern Bucket for First Time in Certain Time Period

• Pattern (Authentication): Entity is Member of Pattern Less Than Some Percent Time

• Pattern (Authentication): Entity is Member of Pattern Less Than Some Percent with All Entities in Picture

• Pattern (Authentication): Entity is Member of Pattern N Times

• Pattern (Authentication): Entity is Member of Pattern N Times in a Given Time Period

C.2.1.1 Pattern (Authentication): Entity is Member of Pattern Bucket for First Time in Certain Time Period

General information about the condition is provided in the following table.

Condition	Entity: Entity is Member of Pattern Bucket for First Time in Certain Time Period
Description	This condition determine whether this entity is member of a pattern bucket for the first time in a certain time period. First time is a relative function. So if you want to track the first time for the membership, then in rule configuration use "Years" as the "Time period type for bucket membership" and specify a long time such as 5 years or so for the "Time period for bucket membership." This pattern operates on first class entities such as user, device, IP, city, state, and country.
Prerequisites	An authentication transaction type pattern has been created with a first class entity member type defined. This pattern operates on first class entities such as user, device, IP, city, state, country.
Assumptions	Autolearning is enabled.
Available since version	10.1.4.5
Checkpoints	All checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
Pattern Name	Name of the pattern for which the "first time" bucket is to be checked.		No
Is	Evaluate this condition to true if this parameter is true and "first time" bucket is true.		No
Time period type for bucket membership	The time period type (hours, days, months, and years)	One of wotk.type.enum. That is (hour, day, month, year)	No
Time period for bucket membership	The time period over which the pattern membership is evaluated. The units of time	Positive integers	No
Member type for pattern-bucket membership	The member type (user, device, location, city, country)	Type for members applicable for that transaction. For authentication type it is one of user, device, IP, city, state, country.	No
First time count	The count of occurrences to compare against	If you are using this rule in a Pre-Authentication (or pre-transaction) scenario, then use a value of 0 since autolearning takes place on the trailing edge of authentication or transaction. For all other checkpoints, use a value of 1 for this parameter. (1 is also a default value)	No

Example Usage

A pattern and rule could be configured to detect if the current access request is the first time the user has accessed from the state they are in now in the given time frame. For example, is this the first time in the last six months that John has logged in from California?

C.2.1.2 Pattern (Authentication): Entity is Member of Pattern Less Than Some Percent Time

General information about the condition is provided in the following table.

Condition	Entity: Entity is Member of Pattern Less than Some Percent Times
Description	Condition determines if the current entity has been a member of the current pattern bucket less than the configured percentage within the time period.
Prerequisites	An authentication transaction type pattern has been created with a first class entity member type defined.
Assumptions	Autolearning is enabled.
Available since version	10.1.4.5
Checkpoints	All checkpoints. This condition can be used in any checkpoint, but if the data is not processed by then, the data used will be stale by a session. This condition is for the authentication type only.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
Pattern Hit Percent less than	If the current entity behavior has occurred less than the specified percentage the condition should trigger.	Only integer values should be used.	No
Pattern name for membership	Name of the pattern this rule condition will evaluate against.		No
Is Membership Count Less than patternHitPercent	This setting controls if the evaluation triggers when it is above or below the specified percentage.		No
Time period type for pattern membership	The time period type (hours, days, months of years)	One of wotk.type.enum. That is (hour, day, month, year)	No
Time period for pattern membership	The time window for the pattern membership evaluation.	Positive integers	No
Member type for pattern membership	The member type (user, device, location, city, country)	Type of members applicable for that transaction. For authentication type, it is one of user, device, IP, city, state, country.	No

Example Usage

Trigger if this user accessed from the current state they are in less than 3% of the time in the last two months. For example, has John logged in from California less than 5% of the time in the last two months?

C.2.1.3 Pattern (Authentication): Entity is Member of Pattern Less Than Some Percent with All Entities in Picture

General information about the condition is provided in the following table.

Condition	Pattern (Authentication): Entity is Member of Pattern Bucket Less Than Some Percent with All Entities in Picture
Description	Condition to determine whether the entity is a member of a pattern bucket some percent of time as compared to all other entities that have been member of this pattern. This condition considers all the other entities; therefore performance is affected more than for simpler conditions.
Prerequisites	Entities and patterns must be defined before adding the condition to the rule/policy
Assumptions	Autolearning is enabled.
Available since version	10.1.4.5
Checkpoints	Condition can be used in any checkpoint, but if data is not processed by then the data used will be stale by a session.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
Pattern bucket hit percent less than	If the current entity behavior has occurred less than the specified percentage the condition should trigger.	Integers. Decimals are not recommended.	No
Pattern name for membership	Name of the pattern this rule condition will evaluate against.		No
Is Membership Count Less than patternHitPercent	This setting controls if the evaluation triggers when it is above or below the specified percentage.		No
Time period type for pattern membership	The time period type (hours, days, months of years)	One of wotk.type.enum. That is (hour, day, month, year)	No
Time period for pattern membership	Time window for the percentage evaluation.	Positive integers	No
Member type for pattern membership	The member type (user, device, location, city, country)	Type of members applicable for that transaction. For authentication type it can be user, device, IP, city, state, or country.	No

Example Usage

Trigger if the current state a user is accessing from is one that other users have utilized a very low percentage of the time within the specified time range. For example, have all users logged in from California less than 5% of the time in the last year?

C.2.1.4 Pattern (Authentication): Entity is Member of Pattern N Times

General information about the condition is provided in the following table.

Condition	Pattern (Authentication): Entity is Member of Pattern N Times
Description	Condition to determine whether this entity is a member of the pattern more than "n" number of times. This condition is intended to be used only with single bucket type patterns since it evaluates pattern membership as opposed to individual bucket membership.
Prerequisites	You should have entities and patterns defined before you try to add this to rule / policy.
Assumptions	Autolearning is enabled.
Available since version	10.1.4.5
Checkpoints	All checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
Pattern hit count more than	If the current entity behavior has occurred more than the specified count, the condition should trigger.	For Pre-Authentication execution, set the count one less than what you want the rule to trigger on.	No
Pattern name for membership	Name of the pattern this rule condition will evaluate against.		No
Is Membership Count More than patternHitCountForUser	Boolean value that is used to return true or false from the condition. It works as follows: if (isMoreThan == true) and (hitCountMorethan returned true) then condition evaluates to true. ELSE if (isMoreThan == false) and (hitCountMorethan returned false) then condition evaluates to false. and condition evaluates to false in all other cases.		No
Time period type for pattern membership	The time period type (hours, days, months of years)	One of wotk.type.enum. That is (hour, day, month, year)	No
Time period for pattern membership	Time window for bucket membership evaluation.	Positive integers	No
Member type for pattern membership	The member type (user, device, location, city, country)	Type of members applicable for that transaction. For authentication type, the type can be user, device, IP, city, state, and country.	No

Example Usage

A single bucket pattern for China is created. Trigger if the current user is coming from China and has accessed from China more than a set number of times within a time range. For example, has John logged in from China more than 4 times in the last six months?

C.2.1.5 Pattern (Authentication): Entity is Member of Pattern N Times in a Given Time Period

General information about the condition is provided in the following table.

Condition	Pattern (Authentication): Entity is Member of Pattern N Times in a Given Time Period
Description	Condition to determine whether this entity has been a member of the current pattern bucket more than "n" number of times within the given time range. This condition is intended to be used only with both single bucket and multi-bucket type patterns. It evaluates individual bucket membership.
Prerequisites	Ensure that the following prerequisites are met: 10.1.4.5.2 or later must be installed. Entities and patterns must be defined before adding this condition to rules/ policies.
Assumptions	Autolearning is enabled.
Available since version	10.1.4.5.2
Checkpoints	All checkpoints

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
Pattern name for membership	Name of the pattern this rule condition will evaluate against.		No
Time period for bucket membership	The time period over which the bucket membership is to be evaluated. This is in units of time.	Use 1 through 23 for hours. 1 through 30 for days. 1 through 12 for months and 1 through 8 for years. Server will use the use the max values if you enter values more than the above specified.	No
Time period type for bucket membership	The time period type (hours, days, months of years)	One of workflow.type.enum. That is (hour, day, month, year)	No
Member type for pattern membership	The member type (user, device, location [city, state, country], IP)	It is one of the type of members applicable for that transaction. For authentication type it is one of user, device, IP, city, state, country.	No
Bucket hit count	The number of request for the application which will be compared against. Hit count for the bucket and the compare operator used in Pattern (Authentication): Entity is Member of Pattern N Times in a Given Time Period evaluate the outcome of the condition together.	For Pre-authentication execution set the count one less than what you want the rule to trigger on.	No
Compare operator for the count	Comparison operator to be used for comparing the count in the system with bucketHitCountForEntity. For example if you specified the compare operator as "Less Than" and bucket hit count as 3, the condition will evaluate to true as long as hit count for that bucket is less than 3 for that authentication.	Possible values are from enum bharosa.numeric.eval.operator.enum equal_to not_equal_to less_than less_than_or_equal_to more_than more_than_or_equal_to are the possible values.	No
Return value if condition is true	Value to return if the condition evaluates to true. If condition does not evaluate to true then opposite of the success value will be returned.	True / False	No
Return value if condition encounters an error	This is the value that will returned if the condition execution runs into issue. Possible errors might be that the pattern is not active, the parameters that were passed (configured) are incorrect or they do not have the values in the expected range.	True / False	No

Example Usage

Trigger if the current user has accessed from the current location less than a set number of times within a time range. For example, out of all the states John has logged in from has he come from California less than 4 times in the last month?

C.2.2 Device Conditions

These section provides information on the following device conditions:

• Device: Browser Header Substring

• Device: Device First Time for User

• Device: Check if Device is of Given Type

• Device: Excessive Use

• Device: In Group

• Device: Is Registered

• Device: Timed Not Status

• Device: Used Count for User

• Device: User Count

• Device: User Status Count

• Device: Velocity from Last Successful Login

C.2.2.1 Device: Browser Header Substring

General information about the condition is provided in the following table.

Condition	Device: Browser Header Substring
Description	Checks whether the supplied string exists as a substring in the browser's header information. The string comparison is performed by ignoring the case (uppercase or lowercase) of the strings.
Prerequisites
Assumptions	The rule is configured through a policy.
Available since version	Pre-10.1.4.5
Checkpoints	All checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
subString	Substring to be checked with the string present in the browser.		Yes

C.2.2.2 Device: Check if Device is of Given Type

General information about the condition is provided in the following table.

Condition	Device: Check if Device is of Given Type
Description	Checks whether the current device is of selected device type. It is very helpful to detect mobile or generic devices.
Prerequisites	None for condition as such. But you must have rule configured with this condition to experience the behavior.
Assumptions
Available since version	11.1.2.0.0
Checkpoints	All checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
Device Type	Select Device type to compare with that of current device	Enumeration. Default is Mobile Device Other possible value is Desktop Device	No
Return value when device is of selected type	Specify the value to be returned if device is of selected type.	Boolean. Default is True. True or False	No

Example Usage

Used to check if the device being used is of given type.

To achieve this, you need to use this condition in a rule.

1. Configure the Devices Type of this condition as Mobile Device and configure the Return value when device is of selected type of this condition as True.

2. Run authentications from a mobile device, and this rule will trigger.

C.2.2.3 Device: Device First Time for User

General information about the condition is provided in the following table.

Condition	Device: Device First Time for User
Description	Checks to see if the user is using this device for the first time. Note that "device" is the combination of the physical device and the browser in most of the test scenarios. Check the page of the recent login to determine the Device ID associated with the login sessions to verify the rule. The user's current (session) device is also counted if is found to be used for the first time.
Prerequisites	The rule should be configured through a policy.
Assumptions
Available since version	Pre-10.1.4.5
Checkpoints	All checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
is	Boolean that checks if the condition should return true or false if the user is using this device for the first time	true (default) or false	No

Example Usage

This condition could potentially be used to determine if the user is logging in from a different device or different devices and to challenge him when it is the case.

C.2.2.4 Device: Excessive Use

General information about the condition is provided in the following table.

Condition	Device: Excessive Use
Description	Checks to see if this device is used excessively. Basically, checks to see if a device was not active for several days and suddenly a large number of users are logging in from the same device in a short period (in a few hours). This condition can be potentially used to track the compromised device of automated programs that obtained access to the code and then tries to log in several users.
Prerequisites	You should have this rule configured through a policy.
Assumptions
Available since version	10.1.4.5
Checkpoints	All checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
userCount	Number of users logging in from a single device in a short period.	positive integers	No
withInHours	This parameter defines the short period in which OAAM must find excessive use.	positive integer	No
notInDays	This parameter describes the number of days the device was not in use.	positive integer	No

Example Usage

This condition can be potentially used to determine if the device used in the current activity is compromised. For example, you might have certain devices that are deemed as compromised and you may want to block users logging in from them. For example, an individual could be "hacking" into a bank computer and then trying to perform various activities. Typically, activity logging should be set up for that computer for several days.

C.2.2.5 Device: In Group

General information about the condition is provided in the following table.

Condition	Device: In Group
Description	Checks to see if the device is in the specified list.
Prerequisites	A list defined already which has devices (IDs) as members. You should have this rule configured through a policy.
Assumptions
Available since version	10.1.4.5
Checkpoints	All checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
isInList	This is a boolean parameter that defines the default return value if the device is in the list.	True / [False]	Yes.
listId	This is the list of IDs of a list of devices. OAAM Admin will display a menu with the possible lists of device lists. Use the Group editor in OAAM Admin to edit the device list.		Yes

Example Usage

This condition can be potentially used to determine if the device of the current activity belongs to a particular list of devices.

For example,

• You may want to block users logging in from the device that is considered "compromised."

• You may not want users to perform certain activities if they are logging in from a device that is a kiosk.

C.2.2.6 Device: Is Registered

General information about the condition is provided in the following table.

Condition	Device: Is Registered
Description	Condition checks to see if the device where that the user is logging in is registered for the user.
Prerequisites	You should have this rule configured through a policy.
Assumptions
Available since version	10.1.4.5
Checkpoints	All checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
is	Boolean parameter to decide if the default return value should be true or false if the device is registered.	[True] / False	Yes

Example Usage

This condition can be used to identify if the user is logging in from a device that he has not registered before. This can basically prevent a fraud where the user's login information is stolen and the thief tries to log in using the user's login information from another otherwise safe location.

C.2.2.7 Device: Timed Not Status

General information about the condition is provided in the following table.

Condition	Device: Timed Not Status
Description	This condition counts the attempts by users from the same device (the device used in the attempt) in the last few seconds where the authentication status is not the one given in the condition. If this count exceeds the count configured in the condition, then this condition evaluates to true.
Prerequisites	You should have this rule configured through a policy.
Assumptions
Available since version	10.1.4.5
Checkpoints	All checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
status	Count the attempts a status that is not equal to this specified status.	auth.status.enum (auth.status.enum.success is the default)	No
withinSeconds	This parameter defines the short period in which the number of login attempts that use that device are counted.	positive integer	No
attempts	Maximum number of attempts to watch for. If the attempt count in Oracle Adaptive Access Manager exceeds this number, then the condition will evaluate to true.	positive integer	No

Example Usage

This condition can be potentially used to determine if the device used in the current activity is compromised. A possible fraud scenario can be detected where:

• An individual (or a automated program) uses the same device to make login attempts and the attempts are either failing or passing based on the data that was stolen.

• A program is used to break the password in an automated fashion.

In these cases, there are repeated failed login attempts from the same device in a short amount of time.

C.2.2.8 Device: Used Count for User

General information about the condition is provided in the following table.

Condition	Device: Used Count for User
Description	This condition counts the attempts by users from the same device (the device used in the attempt) in the last few seconds with an authentication status that is not the one that is specified in the condition. If this count exceeds the count configured in the condition, then this condition evaluates to true.
Prerequisites	You should have this rule configured through a policy.
Assumptions
Available since version	10.1.4.5
Checkpoints	All checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
status	Count the attempts with the status that is not equal to this status.	auth.status.enum (auth.status.enum.success is the default)	No
withinSeconds	This parameter defines the short period in which login attempts using that device are counted.	positive integer	No
attempts	Maximum number of attempts to watch for. If the attempt count exceeds this number then the condition will evaluate to true.	positive integer	No

Example Usage

This condition can be potentially used to determine if the device used in the current activity is compromised.

Possible fraud scenarios that can be detected are:

• An individual (or an automated program) is using same device to make login attempts and the attempts are either failing or passing based on the data that was stolen

• A program is trying to break the password for user in automated fashion

In these cases, repeated failed login attempts are made from the same device in a short period.

C.2.2.9 Device: User Count

General information about the condition is provided in the following table.

Condition	Device: User Count
Description	Check to see if this device is used by several unique users in the last few seconds. This can potentially be fraud since if this condition is true then it will be potentially a compromised device or compromised login information for a number of users.
Prerequisites	You should have this rule configured through a policy.
Assumptions
Available since version	10.1.4.5
Checkpoints	All checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
numberOfUsers	Number of users logging in from the same device in a short period.	positive integers	No
withinSeconds	This parameter defines the short period in which the number of users try to log in to the system using that device.	positive integer	No

Example Usage

This condition can be potentially used to determine if the device used in the current activity is compromised. It could be possible that a fraudster had stolen the login information for several users and tried to ruin their accounts. The result is that many users are logging in from the same device in intervals that are a few seconds each.

C.2.2.10 Device: User Status Count

General information about the condition is provided in the following table.

Condition	Device: User Status Count
Description	Checks user count with the given status from this device in specified duration
Prerequisites	None for condition as such. But you must have rule configured with this condition to experience the behavior.
Assumptions
Available since version	10.1.4.5
Checkpoints	All checkpoints

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
Within	Number of time units to look back in history	Positive Integer. Default = 3	No
Unit of time	Time units to be associated with the within parameter	Integer. time.unit.enum Milliseconds, Seconds, Minutes, Hours, Days, Weeks, Months, Years	No
Max Users Allowed	Max number of users allowed for this condition to start triggering	Positive Integer. Default = 3	No
With Status	Name of the group that is of type auth status.	Long. ID of the group	Yes

Example Usage

Determine if too many users have logins from the logins that failed from the device in the last three hours.

1. Create a Group of Authentication statuses and add "wrong_password" status to this group.

2. Configure the Within parameter to 5.

3. Configure the Unit of time to Minutes.

4. Configure the Max Users Allowed to 3.

5. Configure the With Status to the group name that your created above.

Perform logins from this device with the wrong password for four users. The rule triggers for the fifth login. Wait for longer than 5 minutes, and perform the login again; rule will not trigger.

C.2.2.11 Device: Velocity from Last Successful Login

General information about the condition is provided in the following table.

Condition	Device: Velocity from Last Successful Login
Description	Condition evaluates if the user's velocity in miles per hour is more than the specified value. The location database is used to determine the location of the user for this login and previous login. It takes into account the current session as well. Note that the velocity calculation is dependent on the accuracy of the location data.
Prerequisites	This rule is configured through a policy. Location database should be loaded for the rule.
Assumptions	Location database is loaded.
Available since version	10.1.4.5
Checkpoints	All checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
milesPerHour	Positive number that indicates the user's speed in miles per hour. If the condition determines that the user has traveled faster than this value, then condition will evaluate to true.	positive integer (default is 60)	No
sinceSeconds	Positive integer that specifies the time difference between this login and last successful login to calculate user's velocity.	positive integer (default is 172800 which is 48 hours)	No
Exclude IP List	This parameter allows you to specify a list of IPs to ignore. If a user's IP is from that list, then this condition always evaluates to false. If the user's IP is not in that list or if the list is null or empty, then the condition evaluates the velocity of the user or the device from the last login and evaluates to true if the velocity exceeds the configured value.

Example Usage

This condition can be used to determine the users' location and the risk it poses because of changes in the user's login location between the time of the current login and the last successful login.

Examples are shown below:

For a case with a user traveling by ground transportation, you can configure this rule so that 60 is the value for miles per hour and the time is in seconds for the last successful login (use default values).

Another case involves users traveling on air transport. You can use different values (for example, 500 miles an hour) to ensure that login locations and speed are within reason.

Note:

Be aware that the velocity calculation depends highly on location databases.

C.2.3 Location Conditions

These section provides information on the following location conditions:

• Location: ASN in Group

• Location: in City Group

• Location: In Carrier Group

• Location: In Country Group

• Location: IP Connection Type in Group

• Location: IP in Range Group

• Location: IP Line Speed Type

• Location: IP Maximum Users

• Location: IP Routing Type in Group

• Location: Is IP from AOL

C.2.3.1 Location: ASN in Group

General information about the condition is provided in the following table.

Condition	Location: ASN in Group
Description	Checks to see if the ASN for this IP location is in the group of ASNs that might be of interest. ASN is autonomous system number.
Prerequisites	There should a list of ASNs already defined. You should have this rule configured through a policy.
Assumptions
Available since version
Checkpoints	All checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
Is in group	This is a boolean parameter that defines a default return value if the ASN is in the group.	[True] / False	Yes.
ASN in ASN group	This is a list of ASN groups. The Rule's Conditions tab will display a menu of possible ASNs groups to for this parameter. Use Group editor in OAAM Admin to edit the ASN group.		Yes

Example Usage

This condition can be potentially used to determine if the ASN of the current activity (IP) belongs to a particular group of ASNs. For example you might have certain ASNs those can be deemed as dangerous and you may want to block users logging in from there. Or you might not want users to perform certain activity if they are logging in from an ASN that is from a particular country or region.

C.2.3.2 Location: in City Group

General information about the condition is provided in the following table.

Condition	Location: in City Group
Description	Checks whether the current activity belongs to a given city group.
Prerequisites	There should a group defined already which has cities as members. You should have this rule configured using a policy. IP location data is useful for this condition. (Most production environments will have IP location database populated)
Assumptions
Available since version
Checkpoints	All Checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
Is in group	This is a Boolean parameter that defines a default return value if the city is really in country group.	[True] / False	Yes.
City in city group	This is a list of city groups. The Rule's Conditions tab displays a drop-down of possible groups of cities. Use Group editor in OAAM Admin Console to edit this group list.	(java Long values)	Yes

Example Usage

This condition can be used to figure out if the current activity seems to originate from one of several cities of interest. For example you might have a list of cities and if the current IP of the activity occurs in one of those cities, you can configure the system to take an action or generate an alert.

C.2.3.3 Location: In Carrier Group

General information about the condition is provided in the following table.

Condition	Location: Carrier in Group
Description	Checks to see if the IP is in the given carrier group
Prerequisites	There should a list of carriers already defined. You should have this rule configured using a policy. Location data is helpful for the condition.
Assumptions
Available since version
Checkpoints	All checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
Is in group	This is a Boolean parameter that defines the return value if the carrier is in group or not.	[True] / False	Yes.
IP in carrier group	This is a list of the groups of carriers. The Rule's Condition tab displays drop-down of possible lists of carriers groups to configure for this parameter. Use the Group editor in OAAM Admin Console to edit carrier group.		Yes

Example Usage

This condition can be potentially used to check to see if the carrier of the current activity (IP) belongs to a particular list of carriers. For example you might have certain carriers that can be deemed as "dangerous" (hackers stole all of a carrier's phone numbers recently) and you may want to block users logging in from a carrier, or you might not want users to perform a certain activity if they are logging in from a carrier that is from a particular country or region.

C.2.3.4 Location: In Country Group

General information about the condition is provided in the following table.

Condition	Location: In Country Group
Description	Checks whether the IP belongs to a given country group.
Prerequisites	There should a group defined already which has countries as members. You should have this rule configured using a policy. IP location data is useful for this condition. (Most production environments will have application database populated)
Assumptions
Available since version
Checkpoints	All Checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameters	Description	Possible Value	Can be null?
Is in group	This is a boolean parameter that defines a default return value if the country is in country group.	[True] / False	Yes.
Country in country group	This is a list of group of countries. The Rule's Condition tab will display a drop-down of possible groups. Use the Group editor in OAAM Admin Console to edit the group.	(java Long values)	Yes

Example Usage

This condition can be potentially used to determine if the current activity seems to originate from one of several countries of interest. For example you might have a list of countries and if the current IP used for the activity belongs to one of those countries, then you can configure the policy to take an action or generate an alert.

C.2.3.5 Location: IP Connection Type in Group

General information about the condition is provided in the following table.

Condition	Location: IP Connection Type in Group
Description	Determine whether the connection type of this IP location is in the group of connection types that might be of interest.
Prerequisites	There should a list of connection types already defined. You should have this rule configured using policies.
Assumptions
Available since version
Checkpoints	All Checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
Is in group	This is a boolean parameter that defines a default return value if the IP's connection type is really in connection type group.	[True] / False	Yes.
Connection type in group	This list of connection type groups. The Rule's Condition tab will display a drop-down of possible lists of connection types. Use group editor in administration user interface to edit this group list.		Yes

Example Usage

This condition can be used to determine whether the IP of the current activity comes from a connection type that can be of particular interest to determine fraud. For example, you might have connection type of "satellite link."

C.2.3.6 Location: IP in Range Group

General information about the condition is provided in the following table.

Condition	Location: IP in Range Group
Description	Checks whether the IP of the current activity belongs to a list of IP-ranges specified.
Prerequisites	There should a group defined already which has IP-ranges as members. You should have this rule configured through a policy.
Assumptions
Available since version	10.1.4.5.1
Checkpoints	All checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
Is IP in IP-range group	Use this parameter to indicate a default return value. If the IP belongs to one of the IP ranges, and this parameter is set to true, condition will evaluate to true. If IP belongs to IP range and the parameter is set to false, the condition will return false	[True] / False	Yes.
IP range group	Specify the group that contains the IP ranges. Condition checks if the IP belongs to one of the ranges from this group.		Yes

Example Usage

This condition can be potentially used to determine if the IP of the current activity belongs to one of several ranges of IPs that may be of interest. For example you might have ranges of IPs from a particular subnet and you might want to take action if that is the case.

C.2.3.7 Location: IP Line Speed Type

General information about the condition is provided in the following table.

Condition	Location: IP Line Speed Type
Description	Checks whether the current IP has connection line speed as one of the specified connection speed. This (connection speed) is categorized into High, Medium, Low or Unknown
Prerequisites	You should have this rule configured using a policy. IP location data is useful for this condition. (Most production environments will have IP location database populated)
Assumptions
Available since version
Checkpoints	All Checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
is	This is a boolean parameter that defines a default return value if the connection speed is the one specified.	[True] / False	Yes.
speed type	This is the enumeration value that indicates connection speed type. This (connection speed) is categorized into High, Medium, Low or Unknown The enum that is used for this parameter is location.linespeed.enum	(Integer) Default value is location.linespeed.enum.low	Yes

Example Usage

This condition can be used potentially to determine whether the current activity seems to originate from an IP that has a particular speed type. For example, you may want an alert generated if the speed type is high for the user who usually logs in from a dial-up network.

C.2.3.8 Location: IP Maximum Users

General information about the condition is provided in the following table.

Condition	Location: IP Maximum Users
Description	Condition checks to see if the maximum number of distinct users using the current IP address within the given time duration exceeds the configured condition attribute value. Notice that the current request is also counted in finding the number of unique users from the IP.
Prerequisites	You should have this rule configured using a policy.
Assumptions
Available since version
Checkpoints	All Checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
Seconds elapsed	This is the time period in which the number of users from this IP is to be counted.	integer [Default is 300]	No
The maximum number of users	Maximum number of users allowed.	integer [Default is 5]	No

Example Usage

Use this condition to determine if a particular IP is used by fraudsters to perform logins / transactions by using different login IDs they have stolen. In such cases you see a number of different logins from the same IP during a relatively short period.

C.2.3.9 Location: IP Routing Type in Group

General information about the condition is provided in the following table.

Condition	Location: IP Routing Type in Group
Description	Checks to see if the IP Routing Type is in the group.
Prerequisites	There should a group defined already which has routing types as members. You should have this rule configured using a policy. IP location data is useful for this condition. (Most production environments will have IP location database populated)
Assumptions
Available since version
Checkpoints	All Checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
Is in group	This is a boolean parameter that defines a default return value if the IP routing type is in group.	[True] / False	Yes.
Routing type in group	This is a list of groups of IP routing types. A drop-down of possible lists of IP routing type groups. Use the Group editor in OAAM Admin to edit this group list.	(java Long values)	Yes

Example Usage

This condition can be potentially used to determine whether the current activity is from an IP that belongs to a particular routing type. For example, you might have a list of routing types that can potentially lead to fraud and if the current IP of the activity has one of those routing types, you can configure to take an action or generate an alert.

C.2.3.10 Location: Is IP from AOL

General information about the condition is provided in the following table.

Condition	Location: Is IP from AOL
Description	Determine whether the IP is from AOL proxy
Prerequisites	You should have this rule configured using a policy to test it.
Assumptions
Available since version
Checkpoints	All checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
Is AOL	This is the default return value is IP is indeed from AOL. If the IP is not from AOL then opposite of this attribute is returned.	Boolean [true] / false	No

Example Usage

This condition can be used to figure out if the IP is from an AOL proxy. Customers may want to set up the system to take certain actions for users logging in from AOL.

C.2.4 Session Conditions

The following Session conditions are documented in this section:

• Session: Check Param Value

• Session: Check Param Value in Group

• Session: Check Param Value for Regex

• Session: Check two string param value

• Session: Check String Value

• Session: Time Unit Condition

• Session: Compare Two Parameter Values

• Session: Check Current Session Using the Filter Conditions

• Session: Check Risk Score Classification

• Session: Cookie Mismatch

• Session: Mismatch in Browser Fingerprint

• Session: Compare with Current Date Time

• Session: IP Changed

• Session: Check value in comma separated values

C.2.4.1 Session: Check Param Value

General information about the condition is provided in the following table.

Condition	Session: Check Param Value
Description	Check to see whether the specified parameter value is above the given threshold. This condition can be used to determine whether the value of a particular parameter in the transaction is above some known threshold and then action can be taken accordingly. Basically provided a mathematical function for integrators. This will be very useful in native integration.
Prerequisites	None for condition as such. But you must have rule configured with this condition to experience the behavior.
Assumptions
Available since version	10.1.4.5
Checkpoints	All Checkpoints.

C.2.4.1.1 Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
Is	If the "Is" is true and the value is above the threshold provided then condition evaluates to true. If the "Is" is false and the value is below the threshold provided then condition evaluates to true.	[True] / False	No
ValueKey	The "key" or the look up name of the parameter in the transaction. For example if the transaction is purchase and the name of the attribute is "creditcard" and whose value at Checkpoint is going to be populated by users credit card, then key is "creditcard" in this case. If key is null then defaultError return value is the result of the condition.		Yes
ValueAbove	This is basically the threshold value. This can be used to see if the time is greater than the time parameter present in the transaction. It accepts string representations of long values. Note: If you want to create a rule that uses a decimal value, use the condition Session: Check string param value.	Long values	Yes

C.2.4.1.2 Example Usage

Use this condition when you want to determine whether the value of a particular attribute of the transaction exceeds some threshold.

For example, you configured a transaction called purchase want to trigger a rule whenever the customer purchase exceeds $1000 Mark.

For accomplish this, you must use this rule with this condition.

1. Configure the "ValueKey" of your transaction to "purchase.orderTotal" assuming that you have such an attribute in your transaction.

2. Configure "ValueAbove" to "1000". Configure an alert that says "Too Big Purchase."

3. Process a transaction by providing a few total value numbers above 1000 and a few below 1000.

4. Verify that for the ones above 1000 the rule is triggered.

C.2.4.2 Session: Check Param Value in Group

General information about the condition is provided in the following table.

Condition	Session: Check Param Value in Group
Description	Checks to see if specified parameter value matches the regular expression and the group identified by the expression matcher is in the list of strings. Regular expression matching is not sensitive to case (uppercase and lowercase letters are treated same)
Prerequisites	None for condition as such, but you must have a rule configured with this condition for it to work.
Assumptions
Available since version	10.1.4.5
Checkpoints	All checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Value	Can be Null
Is	If the "Is" is true and the key's value matches the regular expression and the first group string found by the regex matcher is in the string group, then the condition evaluates to "true."	[True] / False	Yes
Parameter Key	The "key" or the look up name of the parameter in the transaction. For example, if the transaction is "internet banking" and the name of the attribute is "bankName" and its value at checkpoint is to be populated by users, then key is "Transaction.bankName" in this case. You should be able to find this key in the Internal ID column in the Transaction Source Data tab in transaction details. If the key is null, then defaultReturnValue is the result of the condition.		Yes
Regular Expression	The character pattern with which you want to match the "value" which has its look up name given by "Parameter Key". In same banking example, if you want to determine whether the bankName equals "SomeBank," you should define this pattern in the policy/rule as "(SomeBank)" without the quotation marks. If the regular expression is null, then defaultReturnValue is the result of the condition.		Yes
In list	The condition checks to see if the character group obtained by the regular expression matcher belongs to this string group. If the list name is null or if the list specified by the name is empty, then defaultReturnValue is the result of the condition.		Yes
Default Return value	If there is any error or if the condition cannot be evaluated because of insufficient data, then return (evaluate to) this value. If this value is not specified (null) then "False" is assumed.	[False] / True	Yes

Example Usage

Use this condition when you want to determine whether some part of the value of a particular attribute of the transaction matches some character pattern, and to see if this part of the value is present in the pre-determined group of strings.

For example, you have configured a transaction called internet banking and you want to trigger a rule if the bank name is "bank1" or "bank2."

To achieve this, you must use this rule with this condition:

1. Configure the "Parameter Key" of your transaction to "Transaction.bankName" (assuming that you have such an attribute in your transaction).

2. Configure "Regular Expression" to "(bank.)". Configure an alert that says "Some specified bank transaction".

3. Create a group of generic strings called "interesting banks" and add "bank1" and "bank2" to it.

4. Configure the group name as "In List" parameter for this condition.

5. Configure "Is" to true and default return value to false.

6. Process a few transaction by providing bank names, "bank1" and "bank2","bank3", and so on. Verify that the alert is generated for "bank1" and "bank2" only.

7. Verify that alerts are generated for "BANK1". This shows that the regular expression matching is not case-sensitive.

C.2.4.3 Session: Check Param Value for Regex

General information about the condition is provided in the following table.

Condition	Session: Check Param Value for Regex
Description	Determine whether the specified parameter value matches regular expression. This condition can be used to determine whether a string value of a particular parameter in the transaction matches a known pattern and then action can be taken accordingly. This provided a mathematical function for integrators and is useful in native integration.
Prerequisites	None for condition as such. But you must have rule configured with this condition to experience the behavior.
Assumptions
Available since version	10.1.4.5
Checkpoints	All Checkpoints.

C.2.4.3.1 Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
Is	If the "Is" is true and regular expression matches to the provided criteria then condition evaluates to true. If the "Is" is false and regular expression does not match to the provided criteria then condition evaluates to true.	[True] / False	No
ValueKey	The "key" or the look up name of the parameter in the transaction. For example if the transaction is purchase and the name of the attribute is "creditcard" and whose value at Checkpoint is going to be populated by users credit card, then key is "creditcard" in this case. If key is null then defaultError return value is the result of the condition. You should be able to find this key in the Internal ID column in Transaction Source Data tab in transaction details.		Yes
Regular Expression	The character pattern with which you want to match the "value" whose look up name is given by "ValueKey". In same credit card example. Check to see whether the user entered all correct in credit card so you might look for pattern "[0-9]".		Yes
Error Return value	If there is any error then return (evaluate to) this value. If this value is not specified (null) then "False" is assumed.	[False] / True	Yes

C.2.4.3.2 Example Usage

Use this condition to determine whether the value of a particular attribute of the transaction matches some character pattern.

For example, you configured a transaction called "purchase" and want to trigger a rule whenever the customer email field ends with ".gov" or ".mil" so you can track government and military business for your firm.

For accomplish this, you must use this rule with this condition.

1. Configure the "ValueKey" of your transaction to "customer.email" assuming that you have such a attribute in your transaction.

2. Configure "Regular Expression" to "*[.gov][.mil]".

3. Configure an alert that says "Government/Military business."

4. Process a few transaction by providing email addresses ending with ".gov" or ".mil".

5. Verify that the alert is generated.

6. Process a few transactions by giving another email address ending with ".com" or any ending other than ".gov" or ".mil".

   Notice that alert is not generated.

C.2.4.4 Session: Check two string param value

General information about the condition is provided in the following table.

Condition	Session: Check two string param value
Description	Check to see whether the specified parameter value is equal to a given character string. This condition can be used to determine whether the value of a particular parameter in the transaction matches an expected string so that action can be taken accordingly. Basically the condition provided a string equality function for integrators. This is useful in native integration. Note that the comparison is case-sensitive. That is "Good" is not equal to "GOOD".
Prerequisites	None for condition as such, but you must configure a rule with this condition for the behavior.
Assumptions
Available since version	10.1.4.5
Checkpoints	All Checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
ValueKey	The "key" or the look up name of the parameter in the transaction. For example if the transaction is purchase and the name of the attribute is "creditCardType" and whose value at Checkpoint is going to be populated by users credit card type, then key is "creditCardType" in this case.		Yes
StringValue	This is basically the value to compare with.		Yes

Example Usage

Use this condition when you want to determine whether the value of a particular attribute of the transaction equals a given string.

For example, you have configured a transaction called purchase and you want to trigger a rule whenever the customer credit card is American Express.

To accomplish this, you must use this rule with this condition:

1. Configure the "ValueKey" of your transaction to "purchase.creditCardType" assuming that you have such an attribute in your transaction.

2. Configure "StrValue" to "AMEX". Configure an alert that says "Amex Card Used"

3. Process a few transactions by providing the card type as AMEX and a few with another card type.

4. Verify that when AMEX is used, the rule is triggered.

C.2.4.5 Session: Check String Value

General information about the condition is provided in the following table.

Condition	Session: Check String Value
Description	Check to see whether the specified parameter value is equal to a given character string. This condition can be used to determine whether the value of a particular parameter in the transaction matches an expected string so that action can be taken accordingly. Basically the condition provided a string equality function for integrators. This is useful in native integration. Note that the comparison is case-sensitive. That is "Good" is not equal to "GOOD".
Prerequisites	None for condition as such, but you must configure a rule with this condition for the behavior.
Assumptions
Available since version	10.1.4.5
Checkpoints	All Checkpoints.

C.2.4.5.1 Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Value	Can be Null?
ValueKey	The "key" or the look up name of the parameter in the transaction. For example if the transaction is purchase and the name of the attribute is "creditCardType" and whose value at Checkpoint is going to be populated by users credit card type, then key is "creditCardType" in this case.		Yes
StringValue	This is basically the value to compare with.		Yes

C.2.4.5.2 Example Usage

Use this condition when you want to determine whether the value of a particular attribute of the transaction equals a given string.

For example, you have configured a transaction called purchase and you want to trigger a rule whenever the customer credit card is American Express.

To accomplish this, you must use this rule with this condition:

1. Configure the "ValueKey" of your transaction to "purchase.creditCardType" assuming that you have such an attribute in your transaction.

2. Configure "StrValue" to "AMEX". Configure an alert that says "Amex Card Used"

3. Process a few transactions by providing the card type as AMEX and a few with another card type.

4. Verify that when AMEX is used, the rule is triggered.

C.2.4.6 Session: Time Unit Condition

General information about the condition is provided in the following table.

Table C-3 Day of Week

Condition	Day of Week
Description	Checks to see if time unit in current date matches certain criteria. The condition determines if a particular time unit (that is part of the current time) belongs to a particular position in the time unit. This condition uses the request date if available to evaluate the date function requested with the help of parameters. If the request date is not available, then current server date time will be used.
Example	This condition can determine if the day of the week is equal to (or not equal to or …) Monday or Tuesday and so on. It can also determine if the day of the month matches certain criteria of the day of the month. It can also try to match the same criteria if month of the year is X or not X or in or not in X.

Parameters

The following table summarizes the parameters in the condition.

Parameters	Description	Possible Values
Time Unit	Enum What is the time unit you are looking for? The default value is Day Of The Week	Possible values are: Day Of the Week Day Of the Month Day of the year Month of the Year Hour of the day Week Of the Month Week Of The year Year
Comparison operator	Enum What comparison you want to make with the time unit. The default value is Equal To	Possible values are: Equal To Not Equal To Less than More Than Less than equal to more than equal to IN not IN
Comparison value	String The default value is "" (empty string), that represents integer or string that represents comma separated integers. Example: "1" or "1,2,3,4". The user can use comma-separated values when using IN or NOT in operator. If comma-separated values are used for any other operators, it will be determined as an error and value of the number 5 parameter (shown in Error Return) will be returned. If the string does not represent number (or a list of comma separated numbers) then it is determined as error and value of parameter number 5 will be returned.	Correct values of this parameter for different time units. Day Of The week: 1 through 7 (1 is Sunday). Day Of the month: 1 through 31 Day of the year: 1 through 366 Month of the year: 0 through 11 (0 is January) Hour of the day: 0 through 23 Week of the Month: 0 through 6 Week of the Year 1 through 53 Year: Positive integer
IS Condition True	Boolean Default value is true This will the return value if the comparison is true.
Error Return value	Boolean Default value is false If the user has configured the value of Comparison Value (#3) incorrectly, or if there is any other error determining date then this value will be returned. The days of the weeks are: 1 = sunday 2 = monday 3 = tuesday 4 = wednesday 5 = thursday 6 = friday 7 = saturday The week day is 2,3,4,5,6 Time Unit is Day of the Week Comparison Operator is "IN" Comparison Value is "1,2,3,4,5" Is Condition True is true Error Return value is "false"

C.2.4.7 Session: Compare Two Parameter Values

General information about the condition is provided in the following table.

Condition	Session: Compare Two Parameter Values
Description	Compares the specified parameter values based on the compare operator, and if based on flag if case (upper / lower) should be used for string type parameters. This condition can be used to check if value of a particular parameter in the transaction is above / below / equal to some other parameter. Basically provided some mathematical function for integrators. Before doing the compare the values of the actual items in the transaction are converted to string (characters) for comparison.
Prerequisites	None for the condition as such, but you must have the rule configured with this condition to experience the behavior.
Assumptions
Available since version	10.1.4.5
Checkpoints	All runtimes

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
Parameter Key1	The "key" or the look up name of the parameter in the transaction. For example if the transaction is purchase and the name of the attribute is "shippingaddresszip" and whose value at runtime is going to be populated by users shipping address zip code, then key is "shippingaddresszip" in this case. If key is null then defRetValue return value is the result of the condition.	String	No
Parameter Key2	The "key" or the look up name of the parameter in the transaction. For example if the transaction is purchase and the name of the attribute is "billingaddresszip" and whose value at runtime is going to be populated by users billing address zip code, then key is "billingaddresszip" in this case. If key is null then defRetValue return value is the result of the condition.	String	No
Operation	This is the compare operation to be used on the values associated with two keys above. This operator is used as result = (value1) [This compare operation] (value2) For example if value1 = numeric amount1 (say = 100.00 Dollars) and value2 = numeric amount2 (say = 53.23 dollars) and this operator is say "more than" then the condition evaluates to 100.00 [ More than] 53.23 === False.	=, <, >, <=, >=, <>, contains, starts with, ends with	Yes
IgnoreCase	Whether case (upper case / lower case) should be ignored for string representations of the parameters.	[True] / False	No
Default Return Value	Default value of the condition if there is any error in getting the params or if one of both of the params cannot be found, or are empty or null.	[False] / True	No

Example Usage

Use this condition whenever you want to compare the values of two attributes of the transaction. For example, you have configured a transaction called purchase and you want to trigger a rule whenever the customer's billing zip code and shipping zip code are not same. For achieving this, you need to use this rule with this condition.

1. Configure the Parameter Key1 of your transaction as purchase.billingZipCode. This assumes that you have such a attribute in your transaction.

2. Configure the Parameter Key2 of your transaction as purchase.shippingZipCode. This assumes that you have such a attribute in your transaction.

3. Configure compareOperator as not equals. Configure an alert that says "Billing and Shipping Code no match."

4. Process a transaction by providing different billing and shipping zip codes.

5. Verify that the rule is triggers. Also verify that if the transaction has the same billing and shipping zip code, the rule does not trigger.

C.2.4.8 Session: Check Current Session Using the Filter Conditions

General information about the condition is provided in the following table.

Condition	Session: Check Current Session Using the Filter Conditions
Description	Compares the attributes of the session with the specified value of the current value. This condition can use up to six filter condition which are logical "AND"ed to get the final result of the condition. This condition lets you build a expression. You can build expression that have the attributes of session also available. Expression building can be viewed as Expr1 = right side variable <Operator> left side variable or Value AND Expr2 = right side variable <Operator> left aide variable or Value .... and so on. You can add up to 6 expressions to build your logic. The variables available are the attributes of the session that are available in the environment when this condition is evaluated.
Prerequisites	None for condition as such, but you must have rule configured with this condition to experience the behavior.
Assumptions
Available since version	11.1.2.0.0
Checkpoints	All Checkpoints except Device ID.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
Check If (or the right side of the expression)	The attribute of the session to be compared. This should be selected from pre-determined list of attributes that are available. It is required to have at least one attribute (row) in the condition.	Drop_Down	No
Operator	Select the appropriate operator from the list of available operators.	Drop Down, select one of <, >, <=, >=, =, Not Equal to, Equals Ignore case, is null, is not null, in, not in, like, not like	No
Value / Current	Choose the value if you want to specify absolute value or current if you want to compare with the current other attribute of the session.	Value / Current	No
Right side of value	If you selected the value in the value/current, you will be provided with the text box to enter the absolute value to be used as right side of expression. If you chose Current in the previous box, then you will get a drop down of the available attributes to compare.	String Value	Yes
and	You can repeat the rows of left side : operator: right side to build your expression.

Example Usage

This condition can be used whenever you want to compare the values of the session and build a chain of expressions and build your own logic

For example, if you want to see if the IP Address of the session is not localhost and users are logging in from Mozilla type browsers. For achieving this, you need to this condition in a rule.

1. Configure on the first expression, "Check If" "IP Address" "Not Equals" "Value" and type in "127.0.0.1" in the box

2. On the second line of expression configure, "AND" "Session.Browser.UserAgent" "Like" "Value" and then type in "Mozilla".

3. Perform logins from an IP Address other than 127.0.0.1 with Mozilla browser, the rule should trigger.

4. Do some logins from same IP Address with other browser say Internet Explorer of Safari or such, the should not trigger.

C.2.4.9 Session: Check Risk Score Classification

General information about the condition is provided in the following table.

Condition	Session: Check Risk Score Classification
Description	Checks the risk score classification based on the risk score from previous checkpoint execution
Prerequisites	None for condition as such, but you must have rule configured with this condition to experience the behavior.
Assumptions
Available since version	11.1.2.0.0
Checkpoints	All Runtimes.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
Classification Type	Type or Range of riskscore. Out of box risk score classified in three types or ranges. (low = 0 to 0, medium = 1 to 500, high = 501 to 1000).	(Integer = 0,1,2) Select from Drop down [0=low], 1=medium, 2=high	No
Default Return Value	Default value of the condition if there is any error.	[False] / True	No

Example Usage

This condition can be used whenever you want to see if the risk score was in pre-determined range in the previous checkpoints for the same session.

For example, if you want to see if the risk score was in high range in any previous checkpoint in this session. The assumption here is you have only 2 checkpoints here namely pre-authentication and post authentication that have policies in them.

For achieving this, you need to use this rule with this condition.

1. Configure the "risk score type" of your condition as "high."

2. Configure "default return value" as "false".

3. Configure this rule in the post authentication checkpoint.

4. In Pre-authentication checkpoint configure a rule that emits a high score. (It can be done by creating the rule in that checkpoint by adding the "always on" condition to it.)

5. Verify that the rule is triggers.

C.2.4.10 Session: Cookie Mismatch

General information about the condition is provided in the following table.

Condition	Session: Cookie Mismatch
Description	Checks to see if there is mismatch of supplied cookie with the expected cookie.
Prerequisites	None
Assumptions
Available since version	10.1.4.5
Checkpoints	All Runtimes except Device ID.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
Fingerprint Type	Fingerprint type enum for the cookie. Valid values will be browser or flash.	[Browser] or Flash	No
CookieKey	Context data key for the cookie value.	String [browser_securecookie] or any String	No
Trigger If Match	If set to true, the condition will evaluate to true if the cookies match.	[True] / False	Yes

Example Usage

This condition can be used whenever you want to check if the expected cookie and the actual cookie coming in from this device matches or not.

To use this condition, add it to a rule and use it in say post authentication checkpoint.

You will need to use a simulator or browser modifier extensions to send another cookie instead of the expected one.

1. Add this condition with default values to the rule.

2. Perform logins to make sure that your logins are from the same device--view the Device ID field in the session data.

3. Now use the browser modifier extension or simulator to send a different cookie than expected one.

This rule should trigger.

C.2.4.11 Session: Mismatch in Browser Fingerprint

General information about the condition is provided in the following table.

Condition	Session: Mismatch in Browser Fingerprint
Description	Checks to see if there is mismatch in browser fingerprint with the fingerprint supplied during authentication. Fingerprint is constructed using the context values passed to Rules Engine.
Prerequisites	None
Assumptions
Available since version	10.1.4.5
Checkpoints	All Runtimes except Device ID.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
User Agent Key	Context data key for browser user agent value.	String [browser_uas] or any String	No
Local Language Key	Key to Local Lang value	String[browser_localLang] or any String	Yes
Local Country Key	Key to Local Country value	String[browser_localCountry] or any String	Yes
localVariantKey	Key to Local Country value	String[browser_localVariant] or any String	Yes
Trigger If Match	If Set (to true), condition is triggered when fingerprints match	[True] / False	Yes

Example Usage

This condition can be used whenever you want to check if the browser fingerprint matches the actual one logging in from the browser for this session.

To use this condition, add it to a rule and use it in the post authentication checkpoint.

You will need to use simulator or browser modifier extensions to send the desired user agent strings.

Add this condition with default values to the rule.

Perform some logins to make sure that your logins are coming in from the same device. View the Device ID field in the session data.

Use the browser modifier extension or simulator to send a different fingerprint than expected one.

The rule should trigger.

C.2.4.12 Session: Compare with Current Date Time

General information about the condition is provided in the following table.

Condition	Session: Compare with current date time
Description	Compare specified parameter value with current time
Prerequisites	None for condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions
Available since version	10.1.4.5
Checkpoints	All Runtimes.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
Parameter Key	The "key" or the look up name of the parameter in the transaction. For example if the transaction is purchase and the name of the attribute is "po_time" and whose value at runtime is going to be populated by date-time type data., then key is "po_time" in this case. If key is null then condition evaluates to false. If key returns a null date object then "IfNull" return value is the result of the condition.	String	Yes
Is after current date?	This is the boolean parameter to configure if the date field should be checked for condition after the current date or before (or equal to) the current date.	Boolean [True]/ False	Yes
If given date key returns empty date (ifNull)	This boolean parameter specifies what to do if the Parameter Key did not return a valid date object from transaction data.	Boolean [True]/ False	Yes

Example Usage

This condition can be used whenever you want to compare the value of the date attribute in a transaction with the transaction date itself.

For example, if you have configured a transaction called "Purchase" and you want to trigger a rule whenever the purchase order date is after the current time.

To achieve this, you need to use this rule with this condition.

Configure the "Parameter Key" of your transaction to "purchase.po_date" assuming that you have such a attribute in your transaction.

Configure the "Is after current date" of your transaction to true.

Configure "If given date key returns empty" to false

Process a few transaction by providing different po_date values.

Verify that the rule is triggers when "po_date" is after the current date.

C.2.4.13 Session: IP Changed

General information about the condition is provided in the following table.

Condition	Session: IP Changed
Description	IP Address is changed since transaction is started
Prerequisites	None for condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions
Available since version	10.1.4.5
Checkpoints	All Runtimes

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
IP Key	The "key" or the look up the IP value in the transaction data.	String	Yes

Example Usage

This condition can be used mostly in transaction related scenarios to compare the value of the IP attribute in a transaction with the current IP address of the session.

For example, if you have configured a transaction called purchase and you want to trigger a rule whenever the IP address coming in the transaction does not match the one that the session is coming from.

To achieve this, you need to use this rule with this condition.

Configure the "IPKey" of your transaction as "purchase.ip_addr" assuming that you have such a attribute in your transaction.

Process a few transaction by providing different ip_addr values.

Verify that the rule is triggers when ip_addr is not the same as the session's IP address.

C.2.4.14 Session: Check value in comma separated values

General information about the condition is provided in the following table.

Condition	Session: Check value in comma separated values
Description	Checks if specified value is present in comma separated value list. Here the comma separated values is the set of values in the transaction data associated with the specified key.
Prerequisites	None for condition as such, but you must have rule configured with this condition to experience the behavior.
Assumptions
Available since version	10.1.4.5
Checkpoints	All Runtimes

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
Value Key	The "key" or the look up the value in the transaction data. The value associated with this key may be comma separated.	String	Yes
Value to Check	Value check against	String	Yes
IsTrue	Condition evaluates to this value if the value of the key is in list	Boolean	True

Example Usage

This condition can be used mostly in transaction related scenarios to compare if one of the data values associated with specified key is the one we are interested in.

For example, you want to identify if the merchant is interested in knowing if the user has stayed in a specified country as part of evaluating the credit card application that is coming in. The countries information comes in as a comma-separated list of strings with country codes. For example: US, UK, and so on.

You configure your transaction as credit_card_application which has a data field that says counties_resided_last_3_years.

Add this condition to the rule that will be executed.

Configure the "ValueKey" of your transaction as "counties_resided_last_3_years"

Configure Value to Check as "US."

Configure isTrue as "True"

Process / perform a few transactions with various combinations of countries resided.

When your comma-separated list of countries resided contains "US" the rule will trigger.

C.2.5 System Conditions

The following transaction conditions are documented in this section:

• System - Check Boolean Property

• System - Check Enough Pattern Data

• System - Check If Enough Data is Available for Any Pattern

• System - Check Int Property

• System - Check Request Date

• System - Check String Property

C.2.5.1 System - Check Boolean Property

General information about the condition is provided in the following table.

Condition	System - Check Boolean Property
Description	Verify if specified property equals true of false.
Prerequisites	None for condition as such. But you must have rule configured with this condition to experience the behavior.
Assumptions
Available since version	10.1.4.5
Checkpoints	All Checkpoints.

C.2.5.1.1 Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Value	Can be Null?
Property	The complete name of the property that must be checked.		Yes
PropertyValue	The expected value of the property. If the property has this value then the condition will evaluate to true.	[True] / false	Yes
Defaultvalue	The value of the property to be used if the property is not found in the system.	[True] / false	Yes

C.2.5.1.2 Example Usage

Use this condition when you want to determine whether the value of a particular property is true or false.

For example, you have a property "trigger.sample.rule" and its value is true.

You want to trigger some rule based on this property.

For accomplish this, you must use this rule with this condition.

1. Configure the "Property" of this condition to "trigger.sample.rule".

2. Configure the PropertyValue to "true".

3. Configure DefaultValue to "false"

4. Run authentication of users to see if the rule triggers.

5. Use the property editor to change the value of the property "trigger.sample.rule" to false.

6. Run authentication of users again and notice that the rule does not trigger.

C.2.5.2 System - Check Enough Pattern Data

General information about the condition is provided in the following table.

Table C-4 System - Check enough pattern data

Details	Description
Condition	System - Check enough pattern data
Description	Checks if enough profiling data is available for a given pattern. This condition checks if pattern data is available in the system for the last several days. It checks only for a particular pattern. So if data is available that is collected by the given pattern for more than the specified number of days, this condition evaluates to true.
Prerequisites	None for condition as such. But you must have a rule configured with this condition to experience the behavior.
Available since version	11.1.2.0
RunTimes	All Runtimes.

Parameters

The following table summarizes the parameters in the condition.

Table C-5 System - Check enough pattern data parameters

Parameter	Description	Possible Values	Can be null?
patternGlobalIdCheckData	Name of the pattern for which the data availability is to be checked.	Pattern names from drop down list	No
numDaysOfDataToCheck	How many days should the condition "look back" from the current login's request time. Typical value is 90 (days). The condition checks these many number of days of data. If pattern profiling data is available for at least these number of days, the condition evaluates to true	Positive integer	No
isPatternDataAvailableDataCheck	Condition evaluates to true if this value is true and there is enough autolearning data OR if this value is false and there is not enough autolearning data. In all other cases, the condition evaluates to false. This parameter basically can be used to decide the outcome of the condition.	[True] / False	Yes
errorReturnValueDataCheck	Value to return if the condition runs into an error.	[False] / True	Yes

Example Usage

Use this condition to check if enough autolearning data exists in the system that had been collected by a given pattern.

"Enough data" can be termed as data gathered over the last several days, depending on the customer scenarios.

For example, this condition can determine if the given autolearning pattern has gathered the data for the last 90 days and based on that, the autolearning rules are used.

The condition provides time for autolearning data to reach statistical stability. If autolearning rules work on a very small set of data, the results may be skewed, depending on how small data sample is.

For example, on a system that just had the pattern enabled today, a customer may want the OAAM Server to gather pattern data for three months before starting testing.

In that case, this condition is useful because it will evaluate to true only after three months (90 days). Then, autolearning rules can trigger and evaluate the risk.

C.2.5.3 System - Check If Enough Data is Available for Any Pattern

General information about the condition is provided in the following table.

Table C-6 System - Check If Enough Data is Available for Any Pattern

Details	Description
Condition	System - Check If Enough Data is Available for Any Pattern
Description	This condition will check if a defined minimum amount of pattern data has been captured int he OAAM database. Generally the threshold should be set to between 1-3 months for best results. The out of the box policies utilize this rule to determine if there is enough pattern data captured to start running pattern based risk analysis.
Prerequisites	None for condition as such, a rule must be configured with this condition to experience the behavior.
Assumptions	Autoleaning is enabled. Without active patterns collecting profiling data, this conditions will not be meaningful.
Available since version	11.1.1.5.0
RunTimes	All Runtimes.

Parameters

The following table summarizes the parameters in the condition.

Table C-7 System - Check If Enough Data is Available for Any Pattern Parameters

Parameter	Description	Possible Value	Can be Null?
numDaysOfDataToCheckAnyPattern	How many days should condition "look back" from the current login's request time. Typical value is 90 (days). Condition checks these many number of days of data. If pattern profiling data is available for at least these number of days, the condition will evaluate to true.	Positive integer	No
isPatternDataAvailableDataCheckAnyPattern	Condition evaluates to true if this value is true and there is enough autolearning data OR if this value is false and there is not enough autolearning data. In all other cases, the condition evaluates to false. This parameter can be used to decide the outcome of the condition.	[True] / False	Yes
errorReturnValueDataCheckAnyPattern	Value to return if the condition runs into an error.	[False] / True	Yes

Possible Scenarios

Use this condition to check if enough autolearning data exists in the system.

"Enough data" can be termed as data gathered over the last several days depending on the customer scenarios.

This condition can determine if any of the autolearning pattern have gathered data for the last 90 days, and based on that, auto learning rules can be used.

This provides time for autolearning data to reach statistical stability. Otherwise, if autolearning rules work on a very small set of data, the results may be skewed depending on how small the data sample is.

For example: on a system that has patterns enabled today, customers may want OAAM Server to gather pattern data for three months before starting to use autolearning rules. In that case, this condition is useful. It evaluates to true only after three months (90 days) and then autolearning rules can trigger and evaluate the risk.

C.2.5.4 System - Check Int Property

General information about the condition is provided in the following table.

Condition	System - Check Integer Property
Description	Verify if specified property equals expected integer value
Prerequisites	None for condition as such. But you must have rule configured with this condition to experience the behavior.
Assumptions
Available since version	10.1.4.5
Checkpoints	All Checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Value	Can be Null?
Property	The complete name of the property that must be checked.		Yes
PropertyValue	The expected value of the property. If the property has this value then the condition will evaluate to true.	Integer	Yes
Defaultvalue	The value of the property to be used if the property is not found in the system.	Integer	Yes

Possible Scenarios

Use this condition when you want to determine whether the value of a particular property equals the expected integer value.

For example, you might have a property "trigger.sample.rule.test.integer" and its value to 25.

You want to trigger some rule based on this property.

For accomplish this, you must use this rule with this condition.

1. Configure the "Property" of this condition to "trigger.sample.rule.test.integer". Configure the PropertyValue to "25".

2. Configure DefaultValue to "30"

3. Run authentication users to see the rule triggers.

4. Use the Property editor to change the value of the property "trigger.sample.rule.test.integer" to 88.

5. Run authentication users again.

   Notice that the rule does not trigger.

C.2.5.5 System - Check Request Date

General information about the condition is provided in the following table.

Condition	System - Check Request Date
Description	Verify if the request date of the transaction or authentication is after a specific date. Notice that only the year, month and day part of the date is used. So basically the "time" portion of the date is ignored when comparing dates.
Prerequisites	None for condition as such. But you must have rule configured with this condition to experience the behavior.
Assumptions
Available since version	10.1.4.5
Checkpoints	All Checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Value	Can be Null?
Date (MM/dd/yyyy)	The date string which the user wants to check the request date against.		No
Is After Request Date	To check to see whether the specified date is after the request date or not after request date Example: If we suppose that request data is today: Case A Set parameter to false if date entered is < today                   it is triggered if date entered is > today                   it is not triggered Case B) Set parameter to true if date entered is < today                   it is not triggered if date entered is > today                   it is triggered	[True] / False	Yes

Example Usage

Use this condition when you want to determine whether the transaction or authentication occurred after a certain date.

For example, if you want to direct users to a certain other policy after a given date, you might use this rule.

To do this, you must use this rule with this condition.

1. Configure the "Date" of this condition to "12/22/2009" if you want to trigger a rule starting the 23rd December of 2009.

2. Configure the "Is After" to "true".

3. Run authentication on users.

   If the date is after 12/22/2009, the rule triggers.

4. Using the Policy editor, change the date in this condition to a future date.

5. Run authentication on the users again.

   Notice that the rule does not trigger.

C.2.5.6 System - Check String Property

General information about the condition is provided in the following table.

Condition	System - Check String Property
Description	Verify if specified property equals expected string value
Prerequisites	None for condition as such. But you must have rule configured with this condition to experience the behavior.
Assumptions
Available since version	10.1.4.5
Checkpoints	All Checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Value	Can be Null?
Property	The complete name of the property that must be checked.		Yes
PropertyValue	The expected value of the property. If the property has this value then the condition will evaluate to true.	String	Yes
Defaultvalue	The value of the property to be used if the property is not found in the system.	String	Yes

Example Usage

Use this condition when you want to determine whether the value of a particular property equals the expected the string value.

For example, you have a property "trigger.sample.rule.test.string" and its value is "test_string". You want to trigger a rule based on this property.

For achieving this, you must use this rule with this condition.

1. Configure the "Property" of this condition to "trigger.sample.rule.test.string".

2. Configure the PropertyValue to "test_string" and configure DefaultValue to "some_other_string"

3. Run authentication on users to trigger the rule.

4. Use the Property editor to change the value of the property "trigger.sample.rule.test.instringteger" to "completely different string value".

5. Run authentication on users again.

   Notice that the rule does not trigger.

C.2.6 Transactions Conditions

These section provides information on the following transaction conditions:

• Transaction: Check Count of Any Entity or Element of a Transaction Using Filter Conditions

• Transaction: Check Current Transaction Using Filter Condition

• Transaction: Check if Consecutive Transactions in Given Duration Satisfy the Filter Conditions

• Transaction: Check Number of Times Entity Used in Transaction.

• Transaction: Check Transaction Aggregrate and Count Using Filter Conditions

• Transaction: Check Transaction Count Using Filter Condition

• Transaction: Compare Transaction Aggregrates (Sum/Avg/Min/Max) Across Two Different Durations

• Transaction: Compare Transaction Counts Across Two Different Durations

• Transaction: Compare Transaction Entity/Element Counts Across Two Different Durations

• Transaction: Check Unique Transaction Entity Count with the specified count

Note:

The filter operators "like" and "not like" work only on transaction data and entity data where the data type is string.

C.2.6.1 Transaction: Check Count of Any Entity or Element of a Transaction Using Filter Conditions

General information about the condition is provided in the following table.

Condition	Transaction: Check Count of Any Entity or Element of a Transaction Using Filter Conditions
Condition	Transaction: Check Count of any entity or element of a Transaction using filter conditions
Description	Check to see whether the count of a transaction entity or entity/data element with a given count where transactions matches ALL the conditions specified. Up to 6 conditions can be specified.
Prerequisites	Ensure that you are using 10.1.4.5.2 or later. Transactions should be defined; Transaction type of the current transaction should be same as the transaction type specified in the rule condition
Assumptions
Available since version	10.1.4.5.2
Checkpoints	All checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
trxDefKey	Transaction Definition fully qualified key. This is specified using list box that has list of transaction definitions		No
elementDefFQKey	Transaction Entity/Element that must be counted for checking		No
durationDescriptor	Duration Descriptor		No
forTheSameCurrentUserId	Boolean flag to indicate whether only transactions belonging to the current user to be counted or not		Yes
ignoreCurrentTransactionInCount	Flag to indicate if the current transaction has to be ignored in the count
specifiedConditionEnumForCount	Condition for the count check. Select only valid operators that are relevant to numeric values		No
specifiedValueForCount	Count value to check. Specify only valid positive integers.		No
applyFilterOnCurrentTransaction	Flag to indicate if the filter conditions have to validated on current transaction before doing the count		No
filter1Key filter2Key filter3Key filter4Key filter5Key filter6Key	These parameters specify the left hand side of the filter conditions. It represents fully qualified key of the transaction field. This field could be an entity field or data field or transaction attribute or request attribute. Note: There is a widget for this that renders list box with all the data fields.		Yes
filter1Condition filter2Condition filter3Condition filter4Condition filter5Condition filter6Condition	These parameters represent the operator and right hand side of the filter condition. It represents fully qualified key of the filter condition. Note: There is a widget for this that renders the list box of operators and a way to specify simple value or group name (in case of IN or NOT IN operator) or select another field in the transaction.		Wherever the filterKey is specified, appropriate condition has to be specified

Example Usage

Use this condition when you want to trigger a rule based on the count of an entity or entity/data element of the transaction.

For example, you configured a transaction called "purchase" and want to trigger a rule if the same user is trying to use more than 5 different credit cards in the last 2 hours and the amount of purchase is more than $100.

To achieve this:

1. Select the "Credit Card" entity name as the one to be counted, so that the rule counts the distinct number of credit cards used.

2. Then, select "For the same current user" flag as true.

3. Then, select the duration as 2 rolling hours and the filter condition as "Amount" greater than 100.

There is provision to specify up to six (6) conditions for filtering the transactions that need to be considered for counting.

C.2.6.2 Transaction: Check Current Transaction Using Filter Condition

General information about the condition is provided in the following table.

Condition	Transaction: Check Current Transaction Using Filter
Description	Check to see whether the current transaction matches ALL the conditions specified. Up to 6 conditions can be specified.
Prerequisites	Transactions should be defined. Transaction type of the current transaction should be the same as the transaction type specified in the rule condition
Assumptions	If there are multiple transactions in the current session, then this condition is applied on the last transaction
Available since version	10.1.4.5.1
Checkpoints	All checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
trxDefKey	Transaction type of the transaction to be counted. It represents the Transaction Definition fully qualified key. This is specified using the list box that has the list of transaction definitions		No
filter1Key filter2Key filter3Key filter4Key filter5Key filter6Key	These parameters specify the left hand side of the filter conditions. The left hand side represents the fully qualified key of the transaction field. This field could be an entity field or data field or transaction attribute or request attribute.		Yes
filter1Condition filter2Condition filter3Condition filter4Condition filter5Condition filter6Condition	These parameters represent the operator and right hand side of the filter condition. The operator and the right hand side represent the fully qualified key of the filter condition. The right hand side is the value, which could be a simple value, the value of the current transaction, or a group. Value: A simple value that is entered into a field Current: A value from the current transaction. A value is selected from a list of values based on the current entities. Group: Group is automatically selected if you chose the condition as IN or NOT IN. After Group is selected, you will have to select a type of group. Then, based on type, a list box appears with other values to select from, and so on.		Wherever the filterKey is specified, an appropriate condition has to be specified

Example Usage

This condition can be used whenever you want to trigger a rule based on checks on the current transaction.

For example, you have configured a transaction called purchase and you want to trigger a rule whenever the amount field of the purchase transaction is greater than $1000 and country is in the list of High Risk countries (that you have configured).

Dollar amounts must be integer values.

For achieving this, you must use this rule with two filter conditions: one for checking if the amount field is greater than 1000 and the second filter condition for checking if the country of the current session is in the list of High Risk countries.

This condition can be used to specify up to six (6) filter conditions on the current transaction.

C.2.6.3 Transaction: Check if Consecutive Transactions in Given Duration Satisfy the Filter Conditions

General information about the condition is provided in the following table.

Condition	Transaction: Check if Consecutive Transactions in Given Duration Satisfy the Filter Conditions
Description	Check to see whether consecutive transactions in a given duration satisfy the specified filter conditions
Prerequisites	Transactions should be defined Transaction type of the current transaction should be same as the transaction type specified in the rule condition Ensure that you are using 10.1.4.5.2 or later.
Assumptions
Available since version	10.1.4.5.2
Checkpoints	All checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
trxDefKey	Transaction Definition fully qualified key. This is specified using list box that has list of transaction definitions		No
durationDescriptor	Duration Descriptor		No
transactionStatusGroupId	Group of Transaction Statuses that should be considered. If no group is specified then Transaction Status is ignored in the query.		Yes
ignoreCurrentTransactionInQuery	Flag to indicate if the current transaction has to be ignored
forTheSameCurrentUserId	Flag to indicate if only transactions belonging to the current user to be counted. If this flag is false then transactions irrespective of users will be considered.		No
allowGapsForChecks	Flag to indicate if gaps are allowed while checking for conditions. If this value is TRUE then gaps would be allowed while checking for conditions.		No
noOfTransactionsToCheckFor1stCheck	Number of transactions that should satisfy the 1st check. Specify positive integers.		No
filter101Key filter102Key filter103Key filter104Key filter105Key filter106Key	Filter Keys for 1st check. These parameters specify the left hand side of the filter conditions. It represents fully qualified key of the transaction field. This field could be an entity field or data field or transaction attribute or request attribute. Note: There is a widget for this that renders list box with all the data fields.		Yes
filter101Condition filter102Condition filter103Condition filter104Condition filter105Condition filter106Condition	Filter Conditions for 1st check. These parameters represent the operator and right hand side of the filter condition. It represents fully qualified key of the filter condition. Note: There is a widget for this that renders the list box of operators and a way to specify simple value or group name (in case of IN or NOT IN operator) or select another field in the transaction.		Wherever the filterKey is specified, appropriate condition has to be specified
noOfTransactionsToCheckFor2ndCheck	Number of transactions that should satisfy the 2nd check. Specify positive integers.		No
filter201Key filter202Key filter203Key filter204Key filter205Key filter206Key	Filter Keys for 2nd check. These parameters specify the left hand side of the filter conditions. It represents fully qualified key of the transaction field. This field could be an entity field or data field or transaction attribute or request attribute. Note: There is a widget for this that renders list box with all the data fields.
filter201Condition filter202Condition filter203Condition filter204Condition filter205Condition filter206Condition	Filter Conditions for 2nd check. These parameters represent the operator and right hand side of the filter condition. It represents fully qualified key of the filter condition. Note: There is a widget for this that renders the list box of operators and a way to specify simple value or group name (in case of IN or NOT IN operator) or select another field in the transaction.		Wherever the filterKey is specified, appropriate condition has to be specified

Example Usage

Use this condition when you want to trigger a rule based on checks that are satisfied on consecutive transactions in a given duration.

For example, you configured a transaction called purchase and want to trigger a rule if the current/last transaction amount is greater than $1000 and there were at least 3 transactions before that where the amount was less than $10.

So, the rule is looking at the last 4 transactions and checking for a fraud pattern of small transactions first and then a big transaction.

Configure a rule with this rule condition and select the appropriate transaction type.

1. Select the number of transactions for the first check as "1" and select the condition to check as "Amount" "Greater Than" 1000, since you want to check only one transaction for the large amount.

2. Select the number of transactions for the second check as "3" and select the condition to check as "Amount" "Less Than" 10, since you want to check 3 transactions for smaller amounts.

3. If you want to allow other transactions in between the checks for the first check and the second check, select "Allow Gaps in Transactions during checks?" as TRUE otherwise select FALSE.

C.2.6.4 Transaction: Check Number of Times Entity Used in Transaction.

General information about the condition is provided in the following table.

Condition	Transaction: Check Number of Times Entity Used in Transaction.
Description	Compares the number of times an entity used has been used with the specified count.
Prerequisites	Transactions should be defined Transaction type of the current transaction should be same as the transaction type specified in the rule condition
Assumptions
Available since version	11.1.2.0
Checkpoints	All Checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
trxDefFQKey	Transaction Definition fully qualified key. This is specified using list box that has list of transaction definitions		No
entityDefFQKey	Select the entity/element to be counted. Only distinct values will be counted		No
specifiedConditionEnum	Specified Condition		No
specifiedCount	Count value to check. Specify only valid positive integers.		No
durationDescriptor	Specify the duration during which the transactions have to be counted. Duration descriptor widget renders the UI for specify the duration. Important: By default durationType is 'rolling' meaning it takes current time as the end point to count the start point. Therefore, if you specify 1 hour using 'rolling' durationType, it simply subtracts 60 minutes from the current time to compute the start time of the duration window. Whenever the duration is described as 'last' x seconds/minutes/hours/days rolling Type duration has to be used. There will be occasions where you want to start the duration window start at zero, and then you should use the durationType as 'calendar'. For example, suppose the current time is 3.35pm and you want to count behavior that happened between 3pm and 3.35 pm then you can specify it has 1 hour with durationType as 'calendar'.		No
transactionStatusEnum	Specify the transaction status that has to be considered for counting. If you want to consider all transactions regardless of their status then don't specify any status		Yes
ignoreCurrentTransactionInCount	Flag to indicate if the current transaction has to be ignored		Yes

Example Usage

This condition can be used whenever you want to trigger a rule based on the number of times the same entity has been used over a specified time period.

For example, you have configured a transaction called purchase and you want to trigger if a credit card is used more than 10 times in one day.

To achieve this, select 'Credit card' as the element to be counted and select 1st duration as 1 calendar day.

Then select comparison condition as 'Greater than' and the specified count as 10.

C.2.6.5 Transaction: Check Transaction Aggregrate and Count Using Filter Conditions

General information about the condition is provided in the following table.

Condition	Transaction: Check Transaction Aggregrate and Count Using Filter
Description	Check the aggregrate of a numeric field and transaction count. You can specify the criteria for transaction to be counted using the filter conditions (up to 6 conditions) and you can also specify the other parameters like duration to be considered and the transaction status to consider and so on.
Prerequisites	Transactions should be defined. Transaction type of the current transaction should be same as the transaction type specified in the rule condition
Assumptions	Aggregrate can be applied only on numeric fields. So the transaction definition should have at least one numeric field.
Available since version	10.1.4.5.1
Checkpoints	All checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
aggregrateFunctionEnum	Aggregrate function to check. Available functions are sum, min, max, avg
elementDefFQKey	Numeric element on which aggregrate check has to be performed. It represents fully qualified key of the numeric field. This is specified using list box that has list of all numeric data fields.		No
specifiedConditionEnumForAggregrate	Operator to be applied for the aggregrate condition. Specify greater than, greater than or equals, less than, less than or equals		No
specifiedValueForAggregrate	Aggregrate numeric value to check		No
specifiedConditionEnumForCount	Operator to be applied for the count condition. Specify greater than, greater than or equals, less than, less than or equals		Yes
specifiedValueForCount	Transaction count numeric value to check		Yes
durationDescriptor	Specify the duration during which the transactions have to be counted. The duration descriptor enables you to specify the duration. Important: By default, durationType is "rolling," meaning it takes the current time as the end point to count backward to the start point. Whenever the duration is described as "last" x seconds/minutes/hours/days, the rolling type duration has to be used. So if you specify 1 day using "rolling" durationType, the "rolling" day starts 24 hours (exactly 1 day) from the current time. For example, if it is 11:33 am, and you specify 1 day, the "rolling" day will start from 11:33 am of the previous day and end at the current time today. There will be occasions where you want to have the duration window start at 0.00. For those occasions, you should use the durationType as "calendar". So if you specify 1 day using "calendar" as the durationType, the "calendar" day will start at 0.00 (12:00 am) of that day and end at the current time. Examples of "rolling" and "calendar": A "calendar" week starts from Sunday regardless of the current day, whereas the "rolling" week starts from 7 days from the current day. A "calendar" month starts from the 1st of the current month, whereas the "rolling" month starts from the same day of the previous month. A "calendar" year starts from January 1st of the current year, whereas the "rolling" year starts from the same day of the previous year. In both the "calendar" and "rolling," the end date/time is the current time. The durationType affects how the startTime of the duration is computed. The "Before" option is used when you want to skip over an interval of time before you begin counting backward to the start point. For example, if you want to calculate 7 days worth of data, but you do not want the data from the last 7 days, you would specify the interval of time you want to skip. If today is February 6, and you want to look at data from January 17 to the 23rd, you would specify "Before" 15 days.		No
transactionStatusEnum	Specify the transaction status that has to be considered for counting. If you want to consider all transactions regardless of their status, do not specify any status		Yes
ignoreCurrentTransactionInCount	Specify if you want to ignore current transaction (if any) in the count. If there are multiple transactions and if this is specified as true, only the last transaction is ignored.		Yes
applyFilterOnCurrentTransaction	Specify if you want to check the filter conditions on the current transaction before performing the count. If the filter conditions fail on the current transaction then the rule condition is evaluated to false without performing the count.
filter1Key filter2Key filter3Key filter4Key filter5Key filter6Key	These parameters specify the left hand side of the filter conditions. The left hand side represents the fully qualified key of the transaction field. This field could be an entity field or data field or transaction attribute or request attribute.
filter1Condition filter2Condition filter3Condition filter4Condition filter5Condition filter6Condition	These parameters represent the operator and right hand side of the filter condition. The operator and the right hand side represent the fully qualified key of the filter condition. The right hand side is the value, which could be a simple value, the value of the current transaction, or a group. Value: A simple value that is entered into a field Current: A value from the current transaction. A value is selected from a list of values based on the current entities. Group: Group is automatically selected if you chose the condition as IN or NOT IN. After Group is selected, you will have to select a type of group. Then, based on type, a list box appears with other values to select from, and so on.		Wherever the filterKey is specified, appropriate condition has to be specified

Example Usage

Use this condition when you want to trigger a rule based on an aggregrate of a transaction numeric value and transaction count.

This is designed to reduce the number of conditions since you can specify checks for both aggregrate and count in a single condition

For example, suppose you have configured a transaction called purchase and you want to challenge if a user is performing a lot of purchases (for example, more than 2 per hour with average amount that is greater than 500) from a high-risk country.

For achieving this, you must use this rule with the following:

1. Specify Aggregrate condition as "Average."

2. Specify Aggregrate value to check as "500."

3. Specify Count condition as "Greater Than Equals."

4. Specify Count to check as "2."

5. Specify the duration with durationType as rolling and duration as 1 hour.

6. Specify false for "Ignore Current Transaction in count?" since you want to consider current transaction in the count.

7. Specify true for "Apply FilterOnCurrentTransaction?" field.

8. One filter condition: for checking if the country of the current session is in the list of High Risk countries.

This condition can be used to specify up to six (6) filter conditions that are applied on transactions that are considered for counting

C.2.6.6 Transaction: Check Transaction Count Using Filter Condition

General information about the condition is provided in the following table.

Condition	Transaction: Check Transaction Count Using Filter
Description	Check the transaction count with a specified value. You can specify the criteria for the transaction to be counted using the filter conditions (up to 6 conditions) and you can also specify the other parameters like the duration to be considered and the transaction status to consider and so on.
Prerequisites	Transactions should be defined. Transaction type of the current transaction should be same as the transaction type specified in the rule condition
Assumptions	If there are multiple transactions in the current session, then this condition is applied on the last transaction
Available since version	10.1.4.5.1
Checkpoints	All checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
trxDefKey	Transaction type of the transaction to be counted. It represents the Transaction Definition fully qualified key. This is specified using the list box that has the list of transaction definitions		No
specifiedConditionEnumForCount	Operator to be applied for the count condition. Specify greater than, greater than or equals, less than, less than or equals		No
specifiedValueForCount	Transaction count numeric value to check		No
durationDescriptor	Specify the duration during which the transactions have to be counted. The duration descriptor enables you to specify the duration. Important: By default, durationType is "rolling," meaning it takes the current time as the end point to count backward to the start point. Whenever the duration is described as "last" x seconds/minutes/hours/days, the rolling type duration has to be used. So if you specify 1 day using "rolling" durationType, the "rolling" day starts 24 hours (exactly 1 day) from the current time. For example, if it is 11:33 am, and you specify 1 day, the "rolling" day will start from 11:33 am of the previous day and end at the current time today. There will be occasions where you want to have the duration window start at 0.00. For those occasions, you should use the durationType as "calendar". So if you specify 1 day using "calendar" as the durationType, the "calendar" day will start at 0.00 (12:00 am) of that day and end at the current time. Examples of "rolling" and "calendar": A "calendar" week starts from Sunday regardless of the current day, whereas the "rolling" week starts from 7 days from the current day. A "calendar" month starts from the 1st of the current month, whereas the "rolling" month starts from the same day of the previous month. A "calendar" year starts from January 1st of the current year, whereas the "rolling" year starts from the same day of the previous year. In both the "calendar" and "rolling," the end date/time is the current time. The durationType affects how the startTime of the duration is computed. The "Before" option is used when you want to skip over an interval of time before you begin counting backward to the start point. For example, if you want to calculate 7 days worth of data, but you do not want the data from the last 7 days, you would specify the interval of time you want to skip. If today is February 6, and you want to look at data from January 17 to the 23rd, you would specify "Before" 15 days.		No
transactionStatusEnum	Specify the transaction status that has to be considered for counting. Do not specify any status if you want to consider all transactions regardless of their status.		Yes
ignoreCurrentTransactionInCount	Specify if you want to ignore the current transaction (if any) in the count. If there are multiple transactions and if this is specified as true, only the last transaction is ignored.		Yes
applyFilterOnCurrentTransaction	Specify if you want to check the filter conditions on the current transaction before performing the count. If the filter conditions fail on the current transaction, then the rule condition is evaluated to false without performing the count.
filter1Key filter2Key filter3Key filter4Key filter5Key filter6Key	These parameters specify the left hand side of the filter conditions. The left hand side represents the fully qualified key of the transaction field. This field could be an entity field or data field or transaction attribute or request attribute.		Yes
filter1Condition filter2Condition filter3Condition filter4Condition filter5Condition filter6Condition	These parameters represent the operator and right hand side of the filter condition. The operator and the right hand side represent the fully qualified key of the filter condition. The right hand side is the value, which could be a simple value, the value of the current transaction, or a group. Value: A simple value that is entered into a field Current: A value from the current transaction. A value is selected from a list of values based on the current entities. Group: Group is automatically selected if you chose the condition as IN or NOT IN. After Group is selected, you will have to select a type of group. Then, based on type, a list box appears with other values to select from, and so on.		Wherever the filterKey is specified, appropriate condition has to be specified

Example Usage

Use this condition when you want to trigger a rule based on transaction count condition.

For example, suppose you have configured a transaction called "purchase" and you want to challenge the user if the user is performing a lot of purchases (for example more than 2 per hour with amount greater than 1000 for each purchase) from a high risk country, you may want to use this condition.

For achieving this, you must use this rule with the following:

1. Specify Count condition as "Greater Than Equals."

2. Specify Count to check as "2."

3. Specify the duration with durationType as rolling and duration as 1 hour.

4. Specify false for "Ignore Current Transaction in count?" since you want to consider current transaction in count.

5. Specify true for "Apply FilterOnCurrentTransaction?" field.

6. Configure two filter conditions:

   • One for checking if the amount field is greater than 1000.

   • Another for checking if the country of the current session is in the list of High Risk countries.

This condition can be used to specify up to six (6) filter conditions that are applied on transactions that are considered for counting.

C.2.6.7 Transaction: Compare Transaction Aggregrates (Sum/Avg/Min/Max) Across Two Different Durations

General information about the condition is provided in the following table.

Condition	Transaction: Compare Transaction Aggregrates (Sum/Avg/Min/Max) Across Two Different Durations
Description	Compare transactions aggregrates across two different durations
Prerequisites	Transactions should be defined Transaction entity/data field that has to be aggregrated should be of type numeric Transaction type of the current transaction should be same as the transaction type specified in the rule condition Ensure that you are using 10.1.4.5.2 or later.
Assumptions
Available since version	10.1.4.5.2
Checkpoints	All checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
trxDefKey	Transaction Definition fully qualified key. This is specified using list box that has list of transaction definitions		No
aggregrateFunctionEnum	Aggregrate function that has to be used		No
elementDefFQKey	Transaction Entity/Data Element that must be aggregrated		No
durationDescriptorFor1stDuration	Select duration for the first aggregrate		No
durationDescriptorFor2ndDuration	Select duration for the second aggregrate		No
comparisonConditionEnum	Comparison condition		No
multiplierFor2ndDurationValue	Multiplier value for the second aggregrate. Only non-zero and null values will be considered		Yes
forTheSameCurrentUserId	Boolean flag to indicate whether only transactions belonging to the current user to be counted or not		Yes
ignoreCurrentTransactionInQuery	Flag to indicate if the current transaction has to be ignored		No
specifiedConditionEnumForCount	Condition for the count check. Select only valid operators that are relevant to numeric values		No
specifiedValueForCount	Count value to check. Specify only valid positive integers.		No
applyFilterOnCurrentTransaction	Flag to indicate if the filter conditions have to validated on current transaction before doing the count		No
filter1Key filter2Key filter3Key filter4Key filter5Key filter6Key	These parameters specify the left hand side of the filter conditions. It represents fully qualified key of the transaction field. This field could be an entity field or data field or transaction attribute or request attribute. Note: There is a widget for this that renders list box with all the data fields.		Yes
filter1Condition filter2Condition filter3Condition filter4Condition filter5Condition filter6Condition	These parameters represent the operator and right hand side of the filter condition. It represents fully qualified key of the filter condition. Note: There is a widget for this that renders the list box of operators and a way to specify simple value or group name (in case of IN or NOT IN operator) or select another field in the transaction.		Wherever the filterKey is specified, appropriate condition has to be specified

Example Usage

Use this condition when you want to trigger a rule based on the comparison of aggregrates of a transaction entity/data element across two different durations.

For example, you configured a transaction called purchase and want to trigger if the sum of the transaction amount for the current day is 20% more than the sum of all transactions amount of the previous day for that user.

To achieve this:

1. Select the "Amount" as the element to be aggregrated and "Sum" as the aggregrate function.

2. Then, select first duration as 1 calendar day and the second duration as 1 calendar day before 1 day.

3. Then select the comparison condition as "Greater than" and multiplier value as 1.2 (100%+20%).

C.2.6.8 Transaction: Compare Transaction Counts Across Two Different Durations

General information about the condition is provided in the following table.

Condition	Transaction: Compare Transaction Counts Across Two Different Durations
Description	Compare transactions counts across two different durations
Prerequisites	Transactions should be defined Transaction type of the current transaction should be same as the transaction type specified in the rule condition Ensure that you are using 10.1.4.5.2 or later.
Assumptions
Available since version	10.1.4.5.2
Checkpoints	All checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
trxDefKey	Transaction Definition fully qualified key. This is specified using list box that has list of transaction definitions		No
durationDescriptorFor1stDuration	Select duration for the first count		No
durationDescriptorFor2ndDuration	Select duration for the second count		No
comparisonConditionEnum	Comparison condition		No
multiplierFor2ndDurationValue	Multiplier value for the second aggregrate. Only non-zero and null values will be considered		Yes
forTheSameCurrentUserId	Boolean flag to indicate whether only transactions belonging to the current user to be counted or not		Yes
ignoreCurrentTransactionInCount	Flag to indicate if the current transaction has to be ignored		No
specifiedConditionEnumForCount	Condition for the count check. Select only valid operators that are relevant to numeric values		No
specifiedValueForCount	Count value to check. Specify only valid positive integers.		No
applyFilterOnCurrentTransaction	Flag to indicate if the filter conditions have to validated on current transaction before doing the count		No
filter1Key filter2Key filter3Key filter4Key filter5Key filter6Key	These parameters specify the left hand side of the filter conditions. It represents fully qualified key of the transaction field. This field could be an entity field or data field or transaction attribute or request attribute. Note: There is a widget for this that renders list box with all the data fields.		Yes
filter1Condition filter2Condition filter3Condition filter4Condition filter5Condition filter6Condition	These parameters represent the operator and right hand side of the filter condition. It represents fully qualified key of the filter condition. Note: There is a widget for this that renders the list box of operators and a way to specify simple value or group name (in case of IN or NOT IN operator) or select another field in the transaction.		Wherever the filterKey is specified, appropriate condition has to be specified

Example Usage

Use this condition when you want to trigger a rule based on the comparison of transaction counts across two different durations.

For example, you configured a transaction called "purchase" and want to trigger the rule if the number of transactions for the current day is 20% more than the number of all transactions of the previous day for that user.

To achieve this:

1. Select the first duration as 1 calendar day and the second duration as 1 calendar day before 1 day.

2. Then, select the comparison condition as "Greater than" and multiplier value as 1.2 (100%+20%).

C.2.6.9 Transaction: Compare Transaction Entity/Element Counts Across Two Different Durations

General information about the condition is provided in the following table.

Condition	Transaction: Compare Transaction Entity/Element Counts Across Two Different Durations
Description	Compare transaction entity/element counts across two different durations
Prerequisites	Transactions should be defined Transaction type of the current transaction should be same as the transaction type specified in the rule condition Ensure that you are using 10.1.4.5.2 or later.
Assumptions
Available since version	10.1.4.5.2
Checkpoints	All checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
durationDescriptorFor1stDuration	Select duration for the first count		No
durationDescriptorFor2ndDuration	Select duration for the second count		No
comparisonConditionEnum	Comparison condition		No
multiplierFor2ndDurationValue	Multiplier value for the second aggregrate. Only non-zero and null values will be considered		Yes
forTheSameCurrentUserId	Boolean flag to indicate whether only transactions belonging to the current user to be counted or not		Yes
ignoreCurrentTransactionInCount	Flag to indicate if the current transaction has to be ignored		No
specifiedConditionEnumForCount	Condition for the count check. Select only valid operators that are relevant to numeric values		No
specifiedValueForCount	Count value to check. Specify only valid positive integers.		No
applyFilterOnCurrentTransaction	Flag to indicate if the filter conditions have to validated on current transaction before doing the count		No
filter1Key filter2Key filter3Key filter4Key filter5Key filter6Key	These parameters specify the left hand side of the filter conditions. It represents fully qualified key of the transaction field. This field could be an entity field or data field or transaction attribute or request attribute. Note: There is a widget for this that renders list box with all the data fields.		Yes
filter1Condition filter2Condition filter3Condition filter4Condition filter5Condition filter6Condition	These parameters represent the operator and right hand side of the filter condition. It represents fully qualified key of the filter condition. Note: There is a widget for this that renders the list box of operators and a way to specify simple value or group name (in case of IN or NOT IN operator) or select another field in the transaction.		Wherever the filterKey is specified, appropriate condition has to be specified

Example Usage

Use this condition when you want to trigger a rule based on the comparison of any transaction entity/element counts across two different durations.

For example, you configured a transaction called "purchase" and want to trigger if the number of distinct credit cards used in the current day is 20% more than the number of distinct credit cards used on the previous day for that user.

To accomplish this:

1. Select "Credit card" as the element to be counted and select the first duration as 1 calendar day and the second duration as 1 calendar day before 1 day.

2. Then, select the comparison condition as "Greater than" and the multiplier value as 1.2 (100%+20%).

C.2.6.10 Transaction: Check Unique Transaction Entity Count with the specified count

General information about the condition is provided in the following table.

Condition	Transaction: Check Unique Transaction Entity Count with the specified count
Description	Check Unique Transaction Entity Count with the specified count
Prerequisites	Transactions should be defined Transaction type of the current transaction should be same as the transaction type specified in the rule condition
Assumptions
Available since version	10.1.4.5
Checkpoints	All Checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
trxDefFQKey (Select Transaction)	Transaction Definition fully qualified key. This is specified using list box that has list of transaction definitions	Select one from list presented on the screen	No
entityDefFQKey (Select Transaction Entity to count)	Select the entity/element to be counted. Only distinct values will be counted		No
specifiedConditionEnum	Specified Condition	Select from drop down list.	No
durationDescriptor	Specify the duration during which the transactions must be counted. The duration descriptor field shows types of durations you can choose from in the user interface. Important: By default the durationType is rolling, meaning it takes the current time as the end point to count the start point. If you specify 1 hour using the rolling durationType, it subtracts 60 minutes from the current time to compute the start time of the duration window. Whenever the duration is described as last x seconds/minutes/hours/days, the rolling type duration has to be used. There will be occasions where you want to start the duration window start at zero, then you should use the durationType as calendar. For example, if the current time is 3.35pm and you want to count something that happened between 3pm and 3.35 pm, then you can specify it has 1 hour with durationType as calendar.	Select from list.	No
transactionStatusEnum	This parameter specifies the transaction status to consider for counting. To consider all transactions regardless of their status, do not specify any status	Enumeration from list Enumeration element of tracker.transaction.status.enum	Yes
forCurrentUser	This parameter specifies whether to evaluate the condition for the current users	Boolean. True or False	No
ignoreCurrentTransactionInCount	Flag to indicate if the current transaction has to be ignored		Yes

Example Usage

This condition can be used whenever you want to trigger a rule based on the number of times the same entity has been used over a specified time period.

For example, you have configured a transaction called "Purchase" and you want to trigger if a credit card is used more than 10 times in one day by the same user. To achieve this, proceed as follows:

1. Select Credit card as the element to be counted and select 1st duration as 1 calendar day.

2. Select forSame User as True.

3. Then select the comparison condition as Greater than and the specified count as 10.

4. Set transactionStatus to Success.

5. Select IgnoreCurrentTransactionCount to True, so that your current transaction will not be counted.

C.2.7 User Conditions

The following user conditions are documented in this section:

• User: Check If Devices Of Certain Type Are Used

• User: Check User Data

• User: Stale Session

• User: Devices Used

• User: Velocity from Last Success

• User: Check Number of Registered Devices Of Given Type

C.2.7.1 User: Check If Devices Of Certain Type Are Used

General information about the condition is provided in the following table.

Condition	User: Check If Devices of a Certain Type are Used
Description	Number of devices of given type used in given time.
Prerequisites	None for condition as such. But you must have rule configured with this condition to experience the behavior.
Assumptions
Available since version	11.1.2.0.0
Checkpoints	All Checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Value	Can be Null?
Number Of Devices	Compare operator for number of actual devices found of given type and the number configured in this condition.	[enumeration] Default is More Than. Possible values are More Than Equal To, Less Than, Less That Equal To, Equal To, Not Equal To	No
Number of devices to compare	Provide the number of devices to be compared with the devices to be found for the user.	[Integer] Default is 0. Provide a positive integer number. (Greater than or equal to 0)	No
Device Of Type	Select Device type to look for.	[Enumeration] Default is Mobile Device Other possible value is Desktop Device	No
Within Duration (seconds)	Time period in seconds to look back into users session history.	[Integer] Default is 3600. Positive integer indicates that condition looks for finite time before this request. 0 value will mean that condition will look for all available history of sessions. If negative value is provided for this parameter then condition will always evaluate to false.	No

Example Usage

This condition can be used whenever you want to check if the user is using too many devices of certain type in certain time period immediately preceding this request. For example, lets say you want to restrict users to use only N number of mobile devices in last 24 hours.

To achieve this, you need to use this condition in a rule.

1. Configure the "Number of Devices" operator of this condition as "Greater Than." Configure the "Number of Devices to compare value of this condition as "N-1".

2. Configure the "Devices of type" of this condition as "Mobile Device" and configure the "within seconds" of this condition as 86400.

3. Run authentications with the registered users and you can see the rule triggering when they have used "N" devices within last 24 hours.

C.2.7.2 User: Check User Data

General information about the condition is provided in the following table.

Condition	User: Check User Data
Description	Verify if specified key has any related data for the user
Prerequisites	None for condition as such, but you must have rule configured with this condition to experience the behavior.
Assumptions
Available since version	10.1.4.5
Checkpoints	All Checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Value	Can be Null?
User Data Key	The complete name of the key which may have associated data for that user. Consider this a property or a configuration property for only that user.	[Strings] Default is email	Yes

Example Usage

This condition can be used whenever you want to check to see whether the user has associated data for the key. For example, you may want to determine whether the user has an email defined in his OTP configuration, so you want to trigger a rule based on whether this email field is defined (non-empty) for the user. To do this, you must use this rule with this condition.

1. Configure the "User Data Key" of this condition with "user_otpContactInfo_email" (for mobile phone, use key to "user_otpContactInfo_mobile").

2. Use the new out-of-the-box base policies that are shipped with 11g. This will force user to register for OTP on the first or second login.

3. Run authentications with the registered users.

   You can see the rule triggering when they are registered for the OTP email (or mobile if you have used that as key).

4. Then go to policy editor and change the value of the key "zoom.some.item.that.is.not.supposed.to.exist."

5. Run authentication users again and notice that the rule does not trigger.

   Notice that the rule does not trigger. (The assumption is that no such key data exists for this usual key)

C.2.7.3 User: Stale Session

General information about the condition is provided in the following table.

Condition	User: Stale Session
Description	Verify if a newer session is established after this session is created
Prerequisites	None for condition as such. But you must have a rule configured with this condition to experience the behavior.
Assumptions
Available since version	10.1.4.5
Checkpoint	All checkpoints.

Example Usage

This condition can be used whenever you want to determine whether the user has established a successful login from another channel while this authentication is in progress.

C.2.7.4 User: Devices Used

Condition	User: Devices Used
Description	Number of devices tried in given time
Prerequisites	None for condition as such, but you must have rule configured with this condition to experience the behavior.
Assumptions
Available since version	10.1.4.5
Checkpoints	All Checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Value	Can be Null?
Number of devices	Provide the number of devices to be compared with the devices to be found for the user.	[Integer] Default = 0. Provide a positive integer number. (>=0)	No
Within Duration (seconds)	Time period in seconds to look back into users session history.	[Integer] Default = 3600. Positive integer indicates that condition looks for finite time before this request. 0 value will mean that condition will look for all available history of sessions. If negative value is provided for this parameter then condition will always evaluate to false.	No

Example Usage

This condition can be used whenever you want to check if the user is using too many devices in certain time period immediately preceding this request.

For example, you want to restrict users to use only N number of devices in last 24 hours.

To achieve this, you need to use this condition in a rule.

1. Configure the "Number of Devices to compare" value of this condition = "N-1".

2. Configure the "within seconds" of this condition = 86400.

3. Run authentications with the registered users and you can see the rule triggering when they have used "N" devices within last 24 hours.

C.2.7.5 User: Velocity from Last Success

General information about the condition is provided in the following table.

Table C-8 User: Velocity from Last Success

Condition	User: Velocity from Last Success
Description	Condition evaluates to check to see if The user's login was successful earlier, and The velocity in miles per hour is more than the specified value, and The user belongs to the same Device ID
Prerequisites	None for condition as such, but you must have the rule configured with this condition
Assumptions
Available since version	10.1.4.5
Checkpoints	All Checkpoints.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Value	Can be Null?
Miles per hour is more than	The velocity in miles per hour is more than specified value	Positive integer Default: 60	No
ignore if last login device is same	See possible value.	True/False The flag is set to true if there are more than one successful login from the same user from the same Device ID. The condition returns false and no action/alert is triggered. if there are more than one successful login from the same user from different Device IDs and the condition returns true and an action/alert is generated. The flag is set to false False ignores the parameter and the condition evaluates based on miles per hour only.	Yes
Exclude IP List	This parameter allows you to specify a list of IPs to ignore. If a user's IP is from that list, then this condition always evaluates to false. If the user's IP is not in that list or if the list is null or empty, then the condition evaluates the velocity of the user or the device from the last login and evaluates to true if the velocity exceeds the configured value.

Scenario

Condition evaluates if the users login was successful earlier and the velocity in miles per hour is more than specified value and user belong to the same Device ID. If there are multiple logins of the same user from the same device, then the parameter "ignore if last login device is same" will act. In order for the condition to be false, there must be multiple logins that are successful from the same user that is using the same Device ID. The location database is used to determine the location of the user for this login and the previous login.

Use Case 1

User: karen1, Device ID: 2106, Previous Device ID: None, rule-flag: true

1. Log in from device from IP1

2. Log in from the same device from IP2 (which is 60 miles away). There is no alert generated.

3. Log in from the same device and IP2 (which is 60 miles away). There is no alert generated.

Table C-9 Use Case 1

User name	Auth Status	Device ID	Location	IP	Alert
karen1	Success	2106	US, Texas, Austin	IP1	No alert
karen1	Success	2106	US, Arizona, Gila Bend	IP2	No alert. An alert is not generated since the same user has the same device and the flag is set to true.
karen1	Success	2106	US, Arizona, Gila Bend	IP2	No alert. An alert is not generated since the same user has the same device and the flag is set to true.

Use Case 2

User: karen1, Device ID: 2107, Previous Device ID: 2106, rule-flag: true

1. Log in from the same device from IP1.

2. Log in from the same device from IP2 (which is 60 miles away). There is no alert triggered.

3. Log in from the same device and IP2 (which is 60 miles away). There is no alert triggered.

Table C-10 Use Case 2

User name	Auth Status	Device ID	Location	IP	Alert
karen1	Success	2107	US, Arizona, Gila Bend	IP1	New device
karen1	Success	2107	US, Texas, Austin	IP2	No alert. An alert is not generated since the same user has the same device and the flag is set to true.
karen1	Success	2107	US, Texas, Austin	IP2	No alert. An alert is not generated since the same user has the same device and the flag is set to true.

Use Case 3

User: karen1, Device ID: 2109, Previous Device ID: 2108, rule-flag: false

1. Log in from Device 2108 from IP1.

2. Log in from Device 2109 from IP2 (which is 60 miles away). Alerts are triggered.

3. Log in from the same device (Device 2109) and IP2 (which is 60 miles away). No alert is triggered.

Table C-11 Use Case 3

User name	Auth Status	Device ID	Location	IP	Alert
karen1	Success	2108	US, Texas, Austin	IP1	New device
karen1	Success	2109	US, Arizona, Gila Bend	IP2	Device High Velocity User High Velocity
karen1	Success	2109	US, Arizona, Gila Bend	IP2	No alert

C.2.7.6 Understanding How the OAAM Device Max Velocity Rule Settings Work

The "Device Max Velocity" rule is used to detect "man in the middle" attacks where a hacker obtains the MAC address for devices that users log in from. Hackers replay the user's login and provide the user's computer MAC address. By doing this they fool the system into thinking the user is logging in from a known and trusted device that is in the user's OAAM profile.

The "Device Max Velocity" rule can detect this type of attack, trigger an alert and block the hacker from successfully signing in. This is accomplished in conjunction with the Quova subscription data. The rule checks to see if the MAC address is in the list of known devices the user is logged in from. Then it examines the IP address location where the user is logged in from. If a hacker then tries to log in by replaying the user's session and also using the user's device MAC address from another location, such as 100 miles away, the rule uses a formula that determines the possibility of that user's device traveling at that velocity.

It is possible for a user to log in to his application, then take a Jet to fly to another city and once again log in to the same application. Therefore you want to be able to adjust the variables of the formula to allow for a portable device to travel at least the speed of a Jet. The "Device Max Velocity" rule has two values that the administrator can configure. Those value fields are called "Last Login Within (Seconds)" and "Miles Per Hour is More Than". Using these two field values you can customize the allotted velocity that a physical device can travel before an alert is triggered.

How the Rule Formula Works

1. The rule first picks up the last successful login in the last N seconds. (If there are multiples, the last one (with the highest timestamp) is picked.

2. The rule looks at cityLastLogin and currentCurrentLogin and calculate the distance between them which "= the distance."

3. Then it calculates thisDistance divided by the difference in login times. That becomes the velocityCalculated.

4. If velocityCalculated is more than velocityConfigured in the rule (from the user interface), the rule triggers.

Solution

Using the following testing assumptions and steps you can make the "Device Max Velocity" rule alert trigger, and also see how to avoid not triggering the rule alert. Before starting your test:

The user's auth status should be "success" in the previous login (N seconds ago).

Assume you only have one minute to test the "Device Max Velocity" rule. Assuming that point A and point B are 900 miles apart, in order to travel from point A to point B in 60 seconds, you need to be traveling at 54000 miles an hour.

1. Set your "Miles Per Hour is More Than" to 54000

2. Set the "Last Login Within (Seconds)" to 60 seconds.

Setting up the Test:

Pick two IP addresses for the test that you know are far away from each other. You are using the following IP addresses from the Quova data:

63.232.120.161 Austin, Texas

63.229.250.34 Phoenix, Arizona

These two cities are a distance of 867 miles apart.

Make sure that the rule is not triggered by logging in twice and not exceeding the "Device Max Velocity" settings you already set to 60 seconds and 54000 miles per hour. Log in twice with the same user and device with logins no less than 75 seconds apart. Make sure that each time you log in you use a tool like Firefox "Modify Headers" to change the IP address between logins using the two IP Addresses mentioned earlier in this section. This simulates a device logging in from two different locations 867 miles apart. The Device Max Velocity alert does not trigger.

Now perform the same test again where you log in twice less than 30 seconds apart, again, changing the IP address between logins. The Device Velocity alert is triggered.

Understanding the relationship between the "Miles Per Hour is More Than" and the "Last Login Within (Seconds)" settings: You cannot change one of these settings and not consider what the other needs to be set to. In other words, you cannot only set the "Mile Per Hour is More Than" setting and not properly adjust the "Last Login within (Seconds)" setting. These two settings work together with the formula to calculate a devices velocity. The relationship between these two settings is not an "OR". It is an "AND". Last Login AND Mile per hour work together. Remember the following two rules before changing these two settings.

1. You cannot only consider the "Miles Per hour" when setting the velocity. You must also consider the "Last Login within (Seconds)" setting.

2. When testing, you must consider and calculate the distance between point A and point B, the time taken to conduct the test, and further factor in the distance between the two points and how long the testing takes. If you want to use one minute as the time allotted for the testing, then make sure you know the distance between point A and Point B. You must also know how long it takes to get from point A and point B in 60 seconds, again, if you plan to conduct your test in less than one minute.

C.2.7.7 User: Check Number of Registered Devices Of Given Type

General information about the condition is provided in the following table.

Condition	User: Check Number of Registered Devices Of Given Type
Description	Number of registered devices of given type.
Prerequisites	None for condition as such, but you must have the rule configured with this condition to experience the behavior.
Assumptions
Available since version	11.1.2.0.0
Checkpoints	All Runtimes.

Parameters

The following table summarizes the parameters in the condition.

Parameter	Description	Possible Values	Can be Null?
Compare Number Of Devices	Compare operator for number of actual registered devices found of given type and the number configured in this condition	[enumeration] Default= More Than More Than Equal To, Less Than, Less That Equal To, Equal To, Not Equal To	No
Number of (registered) devices to compare	Number of devices to compare.	[Integer] Default = 4 Provide a positive number. I this number is less than zero the condition will always evaluate to false.	No
Device of Type	Select Device type to look for.	[Enumeration] Default = Mobile Device Other possible value is Desktop Device	No

Example Usage

This condition can be used whenever you want to check if the user has too many devices registered.

For example, you want to restrict users to use only N number of registered mobile devices.

To achieve this, you need to use this condition in a rule.

Configure the "Number of Devices" operator of this condition as "Greater Than. Configure the "Number of Devices to compare" value of this condition as "4".

Configure the "Devices of type" of this condition as "Mobile Device".

Run a few authentications with the registered users from a new device every time (clear cookies) register those devices for the user.

When user has 5 devices registered and comes in from either a new or an existing device, the rule will be triggered.