B Conditions Reference

Conditions are configurable evaluation statements that are the basic building blocks of decision making in the OAAM rule evaluation process and flow. They use datapoints from historical and runtime data to evaluate risk or business logic. Conditions are grouped based on the type of data used in the condition. For example, user, device, and location. Conditions are pre-packaged in the system and cannot be created by a user. Conditions may take user inputs when adding them to a rule.

This appendix contains the following sections:

• Available Conditions

• Descriptions

• Autolearning Conditions

• Device Conditions

• Location Conditions

• Session Conditions

• System Conditions

• Transactions Conditions

• User Conditions

B.1 Available Conditions

The following table lists the available standard conditions.

Table B-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.
Pattern (Transaction): Entity is a member of the 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 (Transaction): 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 (Transaction): 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 (Transaction): Entity is a member of the pattern N times	Checks 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.
Pattern (Transaction): Entity is a member of the pattern N times in a given time period	Checks 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.
Pattern (Transaction): Entity is member of pattern X% more frequently all entities' average over last N time periods	Checks if this entity has been member of this pattern condition more (or less) frequently than is typical for all entities.
Pattern (Transaction): Entity is member of pattern X% more frequently than entity's average over last N time periods	Checks if this entity has been member of this pattern condition more (or less) frequently than is typical for this entity.
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 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 standard policies use 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 "n" 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 conditions.

Table B-2 Device ID Conditions

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

B.2 Descriptions

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

B.3 Autolearning Conditions

The section provides information on the autolearning conditions.

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

Table B-3 provides general information about the Pattern (Authentication): Entity is Member of Pattern Bucket for First Time in Certain Time Period condition is provided in the following table.

Table B-3 Pattern (Authentication): Entity is Member of Pattern Bucket for First Time in Certain Time Period

Condition	Pattern (Authentication): Entity is Member of Pattern Bucket for First Time in Certain Time Period
Description	The "Pattern (Authentication): Entity is Member of Pattern Bucket for First Time in Certain Time Period" condition determines whether the entity is a member of the "First Time" pattern bucket in a certain time period. "First time" can be considered as a relative function. If you want to truly track "first time" membership, use "Years" as the time period type and a long value such as 5 years around 5 years in the rule / policy configuration.
Prerequisites	An authentication type pattern must be 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. See the First Time count parameter for details on configuring the checkpoint.

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

Table B-4 describes the parameters in the Pattern (Authentication): Entity is Member of Pattern Bucket for First Time in Certain Time Period condition.

Table B-4 Pattern (Authentication): Entity is Member of Pattern Bucket for First Time in Certain Time Period Condition Parameters

Parameter	Description	Possible Values	Can be Null?
Pattern name for bucket First Time	Name of the pattern for which the "first time" pattern bucket is checked.	The following patterns are available out-of-the box: User: Device profiling pattern User: ISP profiling pattern User: Country profiling pattern User: Connection type profiling pattern User: ASN profiling pattern User: State profiling pattern User: Locale profiling pattern User: Day of the week profiling pattern User: Routing type profiling pattern User: Time range profiling pattern You may use other patterns you created. Note: Only active patterns appear in the drop-down list.	No
Is condition True	The Is condition True parameter controls the outcome of the condition. You can negate the outcome of the condition with this parameter. If the user falls in the "First Time" bucket and the value of this parameter is True, the condition evaluates to True. If the user does not fall into the "First Time" bucket and the value of this parameter is False, the condition evaluates to True. In all other cases, the condition evaluates to False.	True or False	No
Time period type for bucket membership	The time period type (hours, days, months, and years)	The time period type is defined in the work.type.enum property. The time period types are hour, day, month, and year. Time period type to select from the drop-down list are: Hours (for "First Time" in the last "n" hours) Days (for "First Time" in the last "n" days) Months (for "First Time" in the last "n" months) Years (for "First Time" in the last "n" years)	No
Time period for bucket membership	The time period over which the bucket membership is evaluated.	Use 1 through 23 for hours. 1 through 30 for days. 1 through 12 for months and 1 through 8 for years. The OAAM Server will use the maximum values if you enter values more than the above specified.	No
Member type for pattern bucket membership	The type of member about which the pattern collects data.	Type of members that is applicable for the transaction. For authentication, select User, Device, IP, City, State, and/or Country.	No
First Time count	The count of occurrences (value) against which the pattern bucket count is compared.	The default value is 1. If the rule is used in a policy that is run in the Preauthentication checkpoint, select 0 as the value since autolearning takes place after the authentication is successful. In the Preauthentication checkpoint, autolearning would not have taken place for the current login. For all other checkpoints (post-authentication and any checkpoints after post-authentication), select 1 as the 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?

B.3.2 Pattern (Authentication): Entity is a Member of the Pattern Less Than Some Percent of Time

Table B-5 provides general information about the Pattern (Authentication): Entity is a member of the pattern less than some percent of time condition.

Table B-5 Pattern (Authentication): Entity is Member of Pattern Less Than Some Percent of Time

Condition	Pattern (Authentication): Entity is Member of Pattern Less Than Some Percent of Time
Description	Checks if this entity has been a member of this pattern condition based on a percent basis
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.

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

Table B-6 describes the Pattern (Authentication): Entity is Member of Pattern Less Than Some Percent of Time condition parameters.

Table B-6 Pattern (Authentication): Entity is Member of Pattern Less Than Some Percent Time Parameters

Parameter	Description	Possible Values	Can be Null?
Pattern hit percent	Percent hit count of the pattern used for comparison. If the current entity behavior has occurred less than the specified percentage and Is Membership Count Less than patternHitPercent parameter is True, the condition triggers. For example, if the rule is to trigger the condition if the user is coming from this pattern less than 10%. The pattern hit percent value is 10. If you create the city pattern and configure the rule to trigger if the user is coming in from a given city less than 10% of the time, the rule triggers when the user comes in from the city until 10% is reached. Pattern Hit Percent is the threshold in which the condition stops triggering.	Use only integer values.	No
Pattern name for membership	Name of the pattern that is used to check the membership count.	The following patterns are available out-of-the box: User: Device profiling pattern User: ISP profiling pattern User: Country profiling pattern User: Connection type profiling pattern User: ASN profiling pattern User: State profiling pattern User: Locale profiling pattern User: Day of the week profiling pattern User: Routing type profiling pattern User: Time range profiling pattern You may use other patterns that you created. Note: Only active patterns appear in the drop-down list.	No
Is Membership Count Less than patternHitPercent	This setting controls if the evaluation triggers when it is above or below the specified percentage. You can use this parameter to negate the outcome of the condition. If this parameter is True and the pattern hit percentage is less than the specified percentage is True, then the condition evaluates to True. If this parameter is False and the pattern hit percentage is less than the specified percentage is False, then the condition evaluates to True. The condition evaluates to False in all other cases.	True or False	No
Time period type for pattern membership	The time period type (hours, days, months, or years)	The time period type is defined in the work.type.enum property. The time period types are hour, day, month, and year. Time period type to select from the drop-down list are: Hours Days Months Years	No
Time period for pattern membership	The time period over which the pattern membership is evaluated.	Use 1 through 23 for hours. 1 through 30 for days. 1 through 12 for months and 1 through 8 for years. The OAAM Server will use the maximum values if you enter values more than the above specified.	No
Member type for pattern membership	The member type (user, device, IP, city, country)	Type of members applicable for that pattern type. Choices for the authentication type are User, Device, IP, City, State, and/or 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?

B.3.3 Pattern (Authentication): Entity is a Member of the Pattern Bucket Less Than Some Percent with All Entities in the Picture

Table B-7 provides general information about the Pattern (Authentication): Entity is a Member of the Pattern Bucket Less Than Some Percent with All Entities in the Picture condition.

Table B-7 Pattern (Authentication): Entity is Member of Pattern Less Than Some Percent with All Entities in Picture

Condition	Pattern (Authentication): Entity is a Member of the Pattern Bucket Less Than Some Percent with All Entities in the Picture
Description	Checks if this entity has been a member of this pattern bucket based on percent basis taking all other entities into account.
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	This condition can be used in any checkpoint, but if data is not processed by then the data used will be stale by a session.

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

Table B-8 describes the parameters in the Pattern (Authentication): Entity is Member of Pattern Less Than Some Percent with All Entities in Picture condition.

Table B-8 Pattern (Authentication): Entity is Member of Pattern Less Than Some Percent with All Entities in Picture Parameters

Parameter	Description	Possible Values	Can be Null?
Pattern bucket hit percent less than	Percent hit count of the pattern that is used for comparison If the current entity behavior has occurred less than the specified percentage, the condition triggers. If Jim logs in 30 times from the city and all users, including Jim, logged in 300 times, Jim's percentage is 10.	Integers. Decimals are not recommended.	No
Pattern name for membership	Name of the pattern for which the membership count is checked.	The following patterns are available out-of-the box: User: Device profiling pattern User: ISP profiling pattern User: Country profiling pattern User: Connection type profiling pattern User: ASN profiling pattern User: State profiling pattern User: Locale profiling pattern User: Day of the week profiling pattern User: Routing type profiling pattern User: Time range profiling pattern You may use other patterns you created. Note: Only active patterns appear in the drop-down list.	No
Is Membership Count Less than patternHitPercent	This setting controls if the evaluation triggers when it is above or below the specified percentage. You can use this parameter to negate the outcome of the condition. If this parameter is True and the pattern hit percentage is less than the specified percentage is True, then the condition evaluates to True. If this parameter is False and the pattern hit percentage is less than the specified percentage is False, then the condition evaluates to True. The condition evaluates to False in all other cases.	True or False	No
Time period type for pattern membership	The time period type (hours, days, months, and years)	The time period type is defined in the work.type.enum property. The time period types are hour, day, month, and year. Time period type to select from the drop-down list are: Hours Days Months Years	No
Time period for pattern membership	The time period over which the pattern membership is evaluated.	Use 1 through 23 for hours. 1 through 30 for days. 1 through 12 for months and 1 through 8 for years. The OAAM Server will use the maximum values if you enter values more than the above specified.	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 used a 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?

B.3.4 Pattern (Authentication): Entity is Member of Pattern N Times

Table B-9 provides general information about the Pattern (Authentication): Entity is Member of Pattern N Times condition.

Table B-9 Pattern (Authentication): Entity is Member of Pattern N Times

Condition	Pattern (Authentication): Entity is Member of Pattern N Times
Description	Checks if this entity has been member of this pattern condition. This condition is intended to be used only with single bucket type patterns. It evaluates individual bucket membership.
Prerequisites	You should have entities and patterns defined before you add this to the rule / policy.
Assumptions	Autolearning is enabled.
Available since version	10.1.4.5
Checkpoints	All checkpoints.

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

The following table summarizes the parameters in the Pattern (Authentication): Entity is Member of Pattern N Times condition.

Table B-10 Pattern (Authentication): Entity is Member of Pattern N Times Parameters

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 triggers.	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.	The following patterns are available out-of-the box: User: Device profiling pattern User: ISP profiling pattern User: Country profiling pattern User: Connection type profiling pattern User: ASN profiling pattern User: State profiling pattern User: Locale profiling pattern User: Day of the week profiling pattern User: Routing type profiling pattern User: Time range profiling pattern You may have other patterns you created to choose from. Note: Only active patterns appear in the drop-down list.	No
Is Membership Count More than patternHitCountForUser	Boolean value that is used to return True or False from the condition. Use this parameter to negate the outcome of the condition. If this parameter is True and the pattern hit count is more than the specified hit count for the user is True, then the condition evaluates to True. If this parameter is False and the pattern hit count is more than the specified hit count for the user is False, then the condition evaluates to True. The condition evaluates to False in all other cases.	True or False	No
Time period type for pattern membership	The time period type (hours, days, months, and years)	The time period type is defined in the work.type.enum property. The time period types are hour, day, month, and year. Time period type to select from the drop-down list are: Hours Days Months Years	No
Time period for pattern membership	The time period over which the pattern membership is evaluated.	Positive integers	No
Member type for pattern membership	The member type (user, device, IP, 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?

B.3.5 Pattern (Authentication): Entity is a Member of the Pattern N Times in a Given Time Period

General information about the Pattern (Authentication): Entity is a Member of the Pattern N Times in a Given Time Period condition is provided in the following table.

Table B-11 Pattern (Authentication): Entity is a Member of the Pattern N Times in a Given Time Period

Condition	Pattern (Authentication): Entity is a Member of the Pattern N Times in a Given Time Period
Description	Checks it the 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 single bucket type patterns.
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

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

The following table summarizes the parameters in the Pattern (Authentication): Entity is a Member of the Pattern N Times in a Given Time Period condition.

Table B-12 Pattern (Authentication): Entity is a Member of the Pattern N Times in a Given Time Period Parameters

Parameter	Description	Possible Values	Can be Null?
Pattern name for membership	Name of the pattern this rule condition will evaluate against.	The following patterns are available out-of-the box: User: Device profiling pattern User: ISP profiling pattern User: Country profiling pattern User: Connection type profiling pattern User: ASN profiling pattern User: State profiling pattern User: Locale profiling pattern User: Day of the week profiling pattern User: Routing type profiling pattern User: Time range profiling pattern You may have other patterns you created to choose from. Note: Only active patterns appear in the drop-down list.	No
Time period for bucket membership	The time period over which the bucket membership is evaluated.	Use 1 through 23 for hours. 1 through 30 for days. 1 through 12 for months and 1 through 8 for years. The OAAM Server will use the maximum values if you enter values more than the above specified.	No
Time period type for bucket membership	The time period type (hours, days, months, and years)	The time period type is defined in the work.type.enum property. The time period types are hour, day, month, and year. Time period type to select from the drop-down list are: Hours Days Months Years	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 a Member of the Pattern N Times in a Given Time Period evaluate the outcome of the condition together.	The default value is 3. For preauthentication execution, set the count to be 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 evaluates to true as long as the hit count for that bucket is less than 3 for that authentication.	Possible values are defined in the bharosa.numeric.eval.operator.enum property: Equal to Less than Less than equal to More than More than equal to Not equal to	No
Return value if condition is true	Value to return if the condition evaluates to True. If the condition does not evaluate to True then the opposite of the success value is returned. For example, if you specify False as the value to return if the condition evaluates to True, False is returned if the condition evaluates to True.	True / False	No
Return value if condition encounters an error	Value returned if the condition execution encounters an issue. Possible errors are that the pattern was not active, incorrect parameters were passed (configured), or values for the parameters were not 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?

Common use cases for this condition involve whitelists and blacklists. For example, "how many times has the user come in from this IP address?" You can create a single bucket type pattern with Remote IP as an attribute, Like as the compare operator, and provide a comma-separated list of IP addresses for the compare value. This condition increments the user's profile when the user comes in from a remote IP from the remote IP address list. You can use this remote IP list to check if the user came in from a certain remote IP address the last 10 times in the last 3 months. You are essentially evaluating the user's behavior against the list of remote IP addresses. For this example, you would not want to create a multi-bucket pattern because this condition would not take advantage of multiple buckets. The condition does not consider how many times the end user individually came from a certain remote IP.

B.3.6 Pattern (Transaction): Entity is Member of Pattern N Times

General information about the Pattern (Transaction): Entity is Member of Pattern N Times condition is provided in the following table.

Table B-13 Pattern (Transaction): Entity is Member of Pattern N Times

Condition	Pattern (Transaction): Entity is Member of Pattern N Times
Description	Checks if this entity has been member of this pattern condition.
Prerequisites	Entities and patterns must be defined before you add this to the rule / policy. The patterns must be active and ones that make use of the transactions in the server.
Assumptions	Auto Learning is enabled.
Available since version	11.1.2.0
Checkpoints	All Checkpoints. Refer to the note for transaction create.

Pattern (Transaction): Entity is Member of Pattern N Times Parameters

The following table summarizes the parameters in the Pattern (Transaction): Entity is Member of Pattern N Times condition.

Table B-14 Pattern (Transaction): Entity is Member of Pattern N Times Parameters

Parameter	Description	Possible Values	Can be Null?
Pattern Hit Count More than	If the current entity behavior has occurred more than the specified value, the condition should trigger.	For transaction create 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.	Choices are only available if there are active patterns that make use of the transactions in the server.	No
Is Membership Count More than patternHitCountForUser	Boolean value that is used to return True or False from the condition. Use this parameter to negate the outcome of the condition. If this parameter is True and the pattern hit count is more than the specified value for the user is True, then the condition evaluates to True. If this parameter is False and the pattern hit count is more than the specified value for the user is False, then the condition evaluates to True. The condition evaluates to False in all other cases.	True or False	No
Time period type for pattern membership	The time period type (hours, days, months, and years)	The time period type is defined in the work.type.enum property. The time period types are hour, day, month, and year. Time period type to select from the drop-down list are: Hours Days Months Years	No
Time period for pattern membership	The time period over which the pattern membership is evaluated.	Use 1 through 23 for hours, 1 through 30 for days, 1 through 12 for months, and 1 through 8 for years. If you enter values that are greater than the maximum values for the time period type, OAAM Server uses the maximum possible values.	No
Member type for pattern membership	The member type (user, device, IP, city, country)	Type of members applicable for that transaction. For authentication type, choices are User, Device, IP, City, State, Country.	No

Example Usage

Trigger if the current destination account has had more than 5 transfers to it between $100 - $500 within the last 8 hours.

B.3.7 Pattern (Transaction): Entity is a Member of the Pattern N Times in a Given Time Period

General information about the Pattern (Transaction): Entity is a Member of the Pattern N Times in a Given Time Period condition is provided in the following table.

Table B-15 Pattern (Transaction): Entity is a Member of the Pattern N Times in a Given Time Period

Condition	Pattern (Transaction): Entity is a Member of the Pattern N Times in a Given Time Period
Description	This condition checks if the 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 single bucket type patterns. It evaluates individual bucket membership.
Prerequisites	Entities and patterns must be defined before you add this to the rule / policy. The patterns must be active and ones that make use of the transactions in the server.
Assumptions	Autolearning is enabled.
Available since version	11.1.2.0
Checkpoints	All checkpoints. See possible values for the bucket hit count in the table following.

Pattern (Transaction): Entity is a Member of the Pattern N Times in a Given Time Period Parameters

The following table summarizes the parameters in the Pattern (Transaction): Entity is a Member of the Pattern N Times in a Given Time Period condition.

Table B-16 Pattern (Transaction): Entity is a Member of the Pattern N Times in a Given Time Period Parameters

Parameter	Description	Possible Values	Can be Null?
Pattern Name for membership	Name of the pattern for which bucket membership is checked. When adding or editing conditions in a rule, select the pattern name from a drop down list of active patterns that are presented.	Choices are only available if there are active patterns that make use of the transactions in the server.	No
Time period for bucket membership	The time period over which the bucket membership is evaluated.	Use 1 through 23 for hours. 1 through 30 for days. 1 through 12 for months and 1 through 8 for years. The OAAM Server will use the maximum values if you enter values more than the above specified.	No
Time period type for bucket membership	The time period type (hours, days, months, and years)	The time period type is defined in the work.type.enum property. The time period types are hour, day, month, and year. Time period type to select from the drop-down list are: Hours Days Months Years	No
Member type for pattern-bucket membership	The member type: user, device, location, and 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 hit count that will be compared against. Hit count for the bucket and the compare operator evaluate the outcome of the condition together.	For Transaction Create execution set the count one less than what you want the rule to trigger on.	No
Compare Operator for the count	Comparison operator to use for comparing the count in the system with Bucket Hit Count. For example if you specify the Compare Operator as Less than and Bucket Hit Count as 3, then if in the system, the condition evaluates to True as long as hit count for that bucket is less than 3 for that authentication.	Possible values are defined in the bharosa.numeric.eval.operator.enum property: Equal to Less than Less than equal to More than More than equal to Not equal to	No
Return value if condition is True	Value to return if the condition evaluates to True. If the condition does not evaluate to True, then the opposite of the success value is returned.	True/False.	No
Return value if condition encounters an error	Value returned if the condition execution encounters an issue. Possible errors are that the pattern was not active, incorrect parameters were passed (configured), or values for the parameters were not in the expected range.	True/False.	No

Example Usage

Trigger if the current originating account has transferred to the current destination account less than a set number of times within a time range. For example, has Account 123456 transferred funds to Account 789012 less than 2 times in the last two months?

B.3.8 Pattern (Transaction): Entity is a Member of the Pattern Bucket for the First Time in a Certain Time Period

General information about the Pattern (Transaction): Entity is a Member of the Pattern Bucket for the First Time in a Certain Time Period condition is provided in the following table.

Table B-17 Pattern (Transaction): Entity is a Member of the Pattern Bucket for the First Time in a Certain Time Period

Condition	Pattern (Transaction): Entity is a Member of the Pattern Bucket for the First Time in a Certain Time Period
Description	Checks if the entity is a member of a pattern bucket for the first time in a certain time period. First time is a relative function. To track first time, in the rule/policy, configure user years as the time period type and use a long value like 5 years.
Prerequisites	Entities and patterns must be defined before you add this to the rule/policy. The patterns must be active and ones that make use of the transactions in the server.
Assumptions	Autolearning is enabled.
Available since version	11.1.2.0
Checkpoints	All checkpoints. Read the details on the First time count parameter for configuring the checkpoint.

Pattern (Transaction): Entity is a Member of the Pattern Bucket for the First Time in a Certain Time Period Parameters

The following table summarizes the parameters in the Pattern (Transaction): Entity is a Member of the Pattern Bucket for the First Time in a Certain Time Period condition.

Table B-18 Pattern (Transaction): Entity is a Member of the Pattern Bucket for the First Time in a Certain Time Period Parameters

Parameter	Description	Possible Values	Can be Null?
Pattern Name for bucket first time	Name of the pattern for which bucket first time is to be checked.	Choices are only available if there are active patterns that make use of the transactions in the server.	No
Is Condition True	Evaluate this condition to True if this parameter is True and first time bucket is True. The Is condition True parameter controls the outcome of the condition. You can negate the outcome of the condition with this parameter. If the user falls in the "First Time" bucket and the value of this parameter is True, the condition evaluates to True. If the user does not fall into the "First Time" bucket and the value of this parameter is False, the condition evaluates to True. In all other cases, the condition evaluates to False.	True or False	No
Time period type for bucket membership	The time period type (hours, days, months, and years)	The time period type is defined in the work.type.enum property. The time period types are hour, day, month, and year. Time period type to select from the drop-down list are: Hours Days Months Years	No
Time period for bucket membership	The time period over which the bucket membership is evaluated.	Use 1 through 23 for hours. 1 through 30 for days. 1 through 12 for months and 1 through 8 for years. The OAAM Server will use the maximum values if you enter values more than the above specified.	No
Member type for pattern-bucket 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
First time count	The count of occurrences (value) against which the pattern bucket count is compared.	The default value is 1. If the rule is used in a policy that is run in the Preauthentication checkpoint, select 0 as the value since autolearning takes place after the authentication is successful. In the Preauthentication checkpoint, autolearning would not have taken place for the current login. For all other checkpoints (post-authentication and any checkpoints after post-authentication), select 1 as the value.	No

Example Usage

Trigger if this is the first time the current originating account has transferred to the current destination account within a time range. For example, is this the first time account 123456 has transferred funds to account 789012 in the last 2 years?

B.3.9 Pattern (Transaction): Entity is a Member of the Pattern Less Than Some Percent of Time

General information about the Pattern (Transaction): Entity is a Member of the Pattern Less Than Some Percent of Time condition is provided in the following table.

Table B-19 Pattern (Transaction): Entity is a Member of the Pattern Less Than Some Percent of Time

Condition	Pattern (Transaction): Entity is a Member of the Pattern Less Than Some Percent of Time
Description	Condition to check if this entity is member of the pattern bucket for less than a certain percent in a certain time period. This condition checks the pattern membership percent against the pattern usage of the same entity. OAAM is counting the entity's membership count for percentage and not the number of entities that belong to that pattern.
Prerequisites	Entities and patterns must be defined before you add this to the rule / policy. The patterns must be active and ones that make use of the transactions in the server.
Assumptions	Autolearning is enabled.
Available since version	11.1.2.0
Checkpoints	All Checkpoints

Pattern (Transaction): Entity is a Member of the Pattern Less Than Some Percent of Time Parameters

The following table summarizes the parameters in the Pattern (Transaction): Entity is a Member of the Pattern Less Than Some Percent of Time condition.

Table B-20 Pattern (Transaction): Entity is a Member of the Pattern Less Than Some Percent of Time Parameters

Parameter	Description	Possible Values	Can be Null?
Pattern Hit Percent less than	Percent hit count of the pattern that will be used for comparison.	Integers The rule will calculate the percentage membership of an entity belonging to a pattern.	No
Pattern Name for membership	Name of the pattern that is used to check the membership percentage.	Choices are only available if there are active patterns that make use of the transactions in the server.	No
Is Membership Count Less than patternHitPercent	This setting controls if the evaluation triggers when it is above or below the specified percentage. Use this parameter to negate the outcome of the condition. If this parameter is True and the pattern hit percent is less than the specified value is True, then the condition evaluates to True. If this parameter is False and the pattern hit percent is more than the specified value is False, then the condition evaluates to True. The condition evaluates to False in all other cases.	True or False	No
Time period type for pattern membership	The time period type (hours, days, months, and years)	The time period type is defined in the work.type.enum property. The time period types are hour, day, month, and year. Time period type to select from the drop-down list are: Hours Days Months Years	No
Time period for pattern membership	The time period over which the pattern membership is evaluated.	Use 1 through 23 for hours. 1 through 30 for days. 1 through 12 for months and 1 through 8 for years. The OAAM Server will use the maximum values if you enter values more than the above specified.	No
Member type for pattern membership	The member type (user, device, location, city, country)	One of the types of members applicable for that transaction. For the authentication type, it is one of user, device, IP, city, state, country.	No

Example Usage

Trigger if the current originating account has transferred to the current destination account less than the specified percent of the time within a time range. For example, has account 123456 transferred funds to account 789012 less than 10% of the time in the last two months?

B.3.10 Pattern (Transaction): Entity is a Member of the Pattern Bucket Less than Some Percent with All Entities in the Picture

General information about the Pattern (Transaction): Entity is a Member of the Pattern Bucket Less than Some Percent with All Entities in the Picture condition is provided in the following table.

Table B-21 Pattern (Transaction): Entity is a Member of the Pattern Bucket Less than Some Percent with All Entities in the Picture

Condition	Pattern (Transaction): Entity is a Member of the Pattern Bucket Less than Some Percent with All Entities in the Picture
Description	Checks if this entity has been member of this pattern bucket based on percent basis, taking into account all other entities
Prerequisites	Entities and patterns should be defined before adding this to a rule / policy.
Assumptions	Autolearning is enabled.
Available since version	11.1.2.0
Checkpoints	Transaction checkpoints

Pattern (Transaction): Entity is a Member of the Pattern Bucket Less than Some Percent with All Entities in the Picture Parameters

The following table summarizes the parameters in the Pattern (Transaction): Entity is a Member of the Pattern Bucket Less than Some Percent with All Entities in the Picture condition.

Table B-22 Pattern (Transaction): Entity is a Member of the Pattern Bucket Less than Some Percent with All Entities in the Picture Parameters

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.	Positive integer	No
Pattern Name for membership	Name of the pattern for which bucket percentage is checked.	Choices are only available if there are active patterns that make use of the transactions in the server.	No
Is Membership Count Less than patternHitPercent	Use this parameter to negate the outcome of the condition. Evaluate this condition to True if this parameter is True and the percentage is less than the specified percentage. Evaluate this condition to True if this parameter is False and the percentage is not less than the specified percentage. The condition evaluates to False in all other cases.	True or False	No
Time period type for pattern membership	The time period type (hours, days, months, and years)	The time period type is defined in the work.type.enum property. The time period types are hour, day, month, and year. Time period type to select from the drop-down list are: Hours Days Months Years	No
Time period for pattern membership	The time period over which the pattern membership is evaluated.	Use 1 through 23 for hours. 1 through 30 for days. 1 through 12 for months and 1 through 8 for years. The OAAM Server will use the maximum values if you enter values more than the above specified.	No
Member type for pattern membership	The member type (user, device, location, city, country)	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

Example Usage

Trigger if less than the specified percent of all users have transferred within the same dollar range the current dollar amount this user is transferring within a time range. For example, John is trying to transfer $625. Have less than 5% of all users performed a funds transfer in the $500-$700 range in the last two months?

B.3.11 Pattern (Transaction): Entity is Member of Pattern X% More Frequently All Entities' Average Over Last N Time Periods

General information about the Pattern (Transaction): Entity is Member of Pattern X% More Frequently All Entities' Average Over Last N Time Periods condition is provided in the following table.

Table B-23 Pattern (Transaction): Entity is Member of Pattern X% More Frequently All Entities' Average Over Last N Time Periods

Condition	Pattern (Transaction): Entity is Member of Pattern X% More Frequently All Entities' Average Over Last N Time Periods
Description	Checks if this entity has been a member of this pattern condition more (or less) frequently than is typical for all entities.
Prerequisites	Entities and patterns must be defined before adding this condition to the rule/policy.
Assumptions	Autolearning is enabled.
Available since version	11.1.2.0
Checkpoints	Transaction checkpoints

Pattern (Transaction): Entity is Member of Pattern X% More Frequently All Entities' Average Over Last N Time Periods Parameters

The following table summarizes the parameters in the Pattern (Transaction): Entity is Member of Pattern X% More Frequently All Entities' Average Over Last N Time Periods condition.

Table B-24 Pattern (Transaction): Entity is Member of Pattern X% More Frequently All Entities' Average Over Last N Time Periods Parameters

Parameter	Description	Possible Values	Can be Null?
Pattern Bucket Hit Percent More than	Percent hit count of the pattern that will be used for comparison.	0 - 100	No
Pattern Name for membership	Name of the pattern for which the bucket membership is to be checked.	Choices are only available if there are active patterns that make use of the transactions in the server.	No
Is current frequency more than average frequency	The parameter controls the outcome of the condition. You can negate the outcome of the condition with this parameter. If the current frequency is more than the average frequency and the value of this parameter is True, the condition evaluates to True. If the current frequency is less than the average frequency and the value of this parameter is False, the condition evaluates to True. In all other cases, the condition evaluates to False.	True/false	No
Time period type for pattern membership	The time period type (hours, days, months, and years)	The time period type is defined in the work.type.enum property. The time period types are hour, day, month, and year. Time period type to select from the drop-down list are: Hours Days Months Years	No
Time period for pattern membership	The time period over which the bucket membership is evaluated.	Use 1 through 23 for hours. 1 through 30 for days. 1 through 12 for months and 1 through 8 for years. The The OAAM Server will use the maximum values if you enter values more than the above specified.	No
Member type for pattern membership	The member type (user, device, location [city, state, country], IP)	Member type applicable for the transaction. For authentication type, it is one of user, device, IP, city, state, country.	No

Example Usage

Mike is a security administrator who needs to profile and evaluate a user's behavior based on the frequency and volume of access requests he makes to an HR application for employee records compared to the access requests of others. Mike wants to track the number of records per 8-hour time period normally accessed by any HR representative. He creates a multi-bucket pattern to capture the count of requests over each 8-hour period for a day. Mike then implements a rule to alert him if the current access falls into an 8-hour range that exceeds the average for all users over the last month by 30%.

1. Define a pattern with user as the member type. Add Time as a Range attribute with start, end, and step as 0, 23, and 8, respectively.

2. Create a rule and add this condition to that rule.

3. Create a policy (Transaction Create Runtime) and add the rule to the policy. While doing this, add the pattern condition when creating the rule and provide the values of 30 and Days for time period and time period type respectively. Choose the value of 30 for the pattern hit percent. Leave other values as default.

4. Configure the alert in the rule if it evaluates to true.

5. Over the course of several days, log in as several users and perform an average of 10 employee record lookup transactions in each eight-hour period. Then, log in and perform 14 employee record lookup transactions in an eight-hour period. Since the current frequency (14) is more than 30% higher than the average frequency for all users (10), the rule triggers and an alert is generated.

B.3.12 Pattern (Transaction): Entity is Member of Pattern X% More Frequently Than Entity's Average Over Last N Time Periods

General information about the Pattern (Transaction): Entity is Member of Pattern X% More Frequently Than Entity's Average Over Last N Time Periods condition is provided in the following table.

Table B-25 Pattern (Transaction): Entity is Member of Pattern X% More Frequently Than Entity's Average Over Last N Time Periods

Condition	Pattern (Transaction): Entity is Member of Pattern X% More Frequently Than Entity's Average Over Last N Time Periods
Description	Checks if this entity has been member of this pattern condition more (or less) frequently than is typical for this entity.
Prerequisites	Entities and patterns must be defined before adding this condition to the rule/policy.
Assumptions	Autolearning is enabled.
Available since version	11.1.2.0
Checkpoints	All Checkpoints, see the note for transaction create.

Pattern (Transaction): Entity is Member of Pattern X% More Frequently Than Entity's Average Over Last N Time Periods Parameters

The following table summarizes the parameters in the Pattern (Transaction): Entity is Member of Pattern X% More Frequently Than Entity's Average Over Last N Time Periods condition.

Table B-26 Pattern (Transaction): Entity is Member of Pattern X% More Frequently Than Entity's Average Over Last N Time Periods Parameters

Parameter	Description	Possible Values	Can be Null?
Pattern Bucket Hit Percent More than	Percent hit count of the pattern that will be used for comparison.	0 - 100	No
Pattern Name for membership	Name of the pattern for which the pattern membership is checked. When adding or editing a condition in a rule, select the pattern name from a drop down of active patterns that will be presented.	Choices are only available if there are active patterns that make use of the transactions in the server.	No
Is current frequency more than average frequency	The parameter controls the outcome of the condition. You can negate the outcome of the condition with this parameter. If the current frequency is more than the average frequency and the value of this parameter is True, the condition evaluates to True. If the current frequency is less than the average frequency and the value of this parameter is False, the condition evaluates to True. In all other cases, the condition evaluates to False.	True/false	No
Time period type for pattern membership	The time period type (hours, days, months, and years)	The time period type is defined in the work.type.enum property. The time period types are hour, day, month, and year. Time period type to select from the drop-down list are: Hours Days Months Years	No
Time period for pattern membership	The time period over which the pattern membership is evaluated.	Use 1 through 23 for hours. 1 through 30 for days. 1 through 12 for months and 1 through 8 for years. The OAAM Server will use the maximum values if you enter values more than the above specified.	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

Example Usage

Mike is a security administrator who needs to profile and evaluate user's behavior based on the frequency and volume of access requests they make to an HR application for employee records. Mike wants to track the number of records per 8-hour time period normally accessed by each HR representative. He creates a multi-bucket pattern to capture the count of requests over each 8-hour period for a day. Mike then implements a rule to alert if the current access falls into an 8-hour range that exceeds the user's average over the last month by 40%.

1. Define a pattern with user as the member type. Add Time as a Range attribute with start, end, and step as 0, 23, and 8, respectively.

2. Create a rule and add this condition to that rule.

3. Create a policy (Transaction Create runtime) and add the above rule to this policy. While doing this choose the pattern you defined from a drop down list available in the Pattern Name list. Choose the values of 30 and Days for time period and time period type respectively. Choose the value of 40 for the pattern hit percent. Leave other values as default.

4. Configure the alert in the rule if it evaluates to true.

5. Over the course of several days, log in as the same user perform an average of 10 employee record lookup transactions in each eight-hour period. Then log in as this user and perform 15 employee record lookup transactions in an eight-hour period. Since the current frequency (15) is more than 40% higher than the average frequency (10), the rule will trigger.

B.4 Device Conditions

These section provides information on the device conditions.

B.4.1 Device: Browser Header Substring

General information about the Device: Browser Header Substring condition is provided in the following table.

Table B-27 Device: Browser Header Substring

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	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	The rule is configured through a policy.
Available since version	Pre-10.1.4.5
Checkpoints	All checkpoints.

Device: Browser Header Substring Parameters

The following table summarizes the parameters in the Device: Browser Header Substring condition.

Table B-28 Device: Browser Header Substring Parameters

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

B.4.2 Device: Check if Device is of Given Type

General information about the Device: Check if Device is of Given Type condition is provided in the following table.

Table B-29 Device: Check if Device is of Given Type

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

Device: Check if Device is of Given Type Parameters

The following table summarizes the parameters in the Device: Check if Device is of Given Type condition.

Table B-30 Device: Check if Device is of Given Type Parameters

Parameter	Description	Possible Values	Can be Null?
Device Type	Select Device type to compare with that of current device	Enumeration The 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. True or False The default is True.	No

Example Usage

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

To achieve this, you must 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.

B.4.3 Device: Device First Time for User

General information about the Device: Device First Time for User condition is provided in the following table.

Table B-31 Device: Device First Time for User

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	None
Available since version	Pre-10.1.4.5
Checkpoints	All checkpoints.

Device: Device First Time for User Parameters

The following table summarizes the parameters in the Device: Device First Time for User condition.

Table B-32 Device: Device First Time for User Parameter

Parameter	Description	Possible Values	Can be Null?
Is	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 is used to determine if the user is logging in using this device for the first time irrespective of the status.

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.

B.4.4 Device: Excessive Use

General information about the Device: Excessive Use condition is provided in the following table.

Table B-33 Device: Excessive Use

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	None
Available since version	10.1.4.5
Checkpoints	All checkpoints.

Device: Excessive Use Parameters

The following table summarizes the parameters in the Device: Excessive Use condition.

Table B-34 Device: Excessive Use Parameters

Parameter	Description	Possible Values	Can be Null?
Number of users	Number of users logging in from a single device in a short period.	positive integers	No
Within (hours)	This parameter defines the short period in which OAAM must find excessive use.	positive integer	No
and not used in (days)	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.

B.4.5 Device: In Group

General information about the Device: In Group condition is provided in the following table.

Table B-35 Device: In Group

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	None
Available since version	10.1.4.5
Checkpoints	All checkpoints.

Device: In Group Parameters

The following table summarizes the parameters in the Device: In Group condition.

Table B-36 Device: In Group Parameters

Parameter	Description	Possible Values	Can be Null?
Is in group	The parameter controls the outcome of the condition. You can negate the outcome of the condition with this parameter. If the device is in the group and the value of this parameter is True, the condition evaluates to True. If the device is not in the group and the value of this parameter is False, the condition evaluates to True. In all other cases, the condition evaluates to False.	True / [False]	Yes.
Device in group	This is the list of IDs of a list of devices. The OAAM Administration Console will display a menu with the possible lists of device lists. Use the Group editor in the OAAM Administration Console 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.

For more information on group creation, see Chapter 13, "Managing Groups."

B.4.6 Device: Is Registered

General information about the Device: Is Registered condition is provided in the following table.

Table B-37 Device: Is Registered

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	None
Available since version	10.1.4.5
Checkpoints	All checkpoints.

Device: Is Registered Parameters

The following table summarizes the parameters in the Device: Is Registered condition.

Table B-38 Device: Is Registered Parameters

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

Example Usage

Use this condition 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.

B.4.7 Device: Timed Not Status

General information about the Device: Timed Not Status condition is provided in the following table.

Table B-39 Device: Timed Not Status

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	None
Available since version	10.1.4.5
Checkpoints	All checkpoints.

Device: Timed Not Status Parameters

The following table summarizes the parameters in the Device: Timed Not Status condition.

Table B-40 Device: Timed Not Status Parameters

Parameter	Description	Possible Values	Can be Null?
status	Count the attempts that are not equal to this specified status. Authentication status is configured through auth.status.enum. For example: Blocked Locked Database Error Password Expired Invalid User Pending Pending activation Session expired Session reused Success System Error User is disabled Wrong answer Wrong password Wrong pin	auth.status.enum (auth.status.enum.success is the default)	No
within seconds	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 manner.

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

B.4.8 Device: Used Count for User

General information about the Device: Used Count for User condition is provided in the following table.

Table B-41 Device: Used Count for User

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	None
Available since version	10.1.4.5
Checkpoints	All checkpoints.

Device: Used Count for User Parameters

The following table summarizes the parameters in the Device: Used Count for User condition.

Table B-42 Device: Used Count for User Parameters

Parameter	Description	Possible Values	Can be Null?
Authentication Status	Count the attempts with the status that are not equal to this status.	auth.status.enum (auth.status.enum.success is the default)	No
more than	Maximum number of attempts to watch for. If the attempt count exceeds this number then the condition will evaluate to true.	positive integer	No
Is	The parameter controls the outcome of the condition. You can negate the outcome of the condition with this parameter. If the count exceeds the count specified in the condition and the authentication is not equal to the status specified in the condition, the condition evaluates to True. If the count does not exceed the count specified in the condition and the authentication is equal to the status specified in the condition, the condition evaluates to True. In all other cases, the condition evaluates to False.	True or False	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.

B.4.9 Device: User Count

General information about the Device: User Count condition is provided in the following table.

Table B-43 Device: User Count

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	None
Available since version	10.1.4.5
Checkpoints	All checkpoints.

Device: User Count Parameters

The following table summarizes the parameters in the Device: User Count condition.

Table B-44 Device: User Count Parameters

Parameter	Description	Possible Values	Can be Null?
Seconds elapsed	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
The maximum number of users allowed	Number of users logging in from the same device in a short period.	positive integers	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.

B.4.10 Device: User Status Count

General information about the Device: User Status Count condition is provided in the following table.

Table B-45 Device: User Status Count

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

Device: User Status Count Parameters

The following table summarizes the parameters in the Device: User Status Count condition.

Table B-46 Device: User Status Count Parameters

Parameter	Description	Possible Values	Can be Null?
Within	Number of time units to look back in history	Positive Integer. The default is 3.	No
Time Unit	Time units to be associated with the "Within" parameter	Select a time unit configured from the time.unit.enum property: Milliseconds, Seconds, Minutes, Hours, Days, Weeks, Months, Years	No
Maximum number of users allowed	Maximum number of users allowed for this condition to start triggering	Positive Integer The default is 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 Time Unit to Minutes.

4. Configure the Maximum number of 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.

B.4.11 Device: Velocity from Last Login and Ignore IP Group

General information about the Device: Velocity from Last Login and Ignore IP Group condition is provided in the following table.

Table B-47 Device: Velocity from Last Successful Login

Condition	Device: Velocity from Last Login and Ignore IP Group
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.

Device: Velocity from Last Login and Ignore IP Group Parameters

The following table summarizes the parameters in the Device: Velocity from Last Login and Ignore IP Group condition.

Table B-48 Device: Velocity from Last Login and Ignore IP Group Parameters

Parameter	Description	Possible Values	Can be Null?
Miles per Hour is more than	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. Miles per hour is the ratio of the distance traveled (in miles) to the time spent traveling (in hours).	positive integer The default is 60.	No
Last login within (Seconds)	Positive integer that specifies the time difference between this login and last successful login to calculate user's velocity.	positive integer The default is 172800 which is 48 hours.	No
Ignore IP Group	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

Use this condition 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).

• For 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.

B.4.12 Device: Check if Device is Using Mobile Browser

General information about the Device: Check if Device is Using Mobile Browser condition is provided in the following table.

Table B-49 Device: Check if Device is Using Mobile Browser

Condition	Device: Check if Device is Using Mobile Browser
Description	Checks whether the current device is using a mobile browser to access the site based on the user agent string. A mobile browser is a web browser designed for use on a mobile device such as a mobile phone or PDA.
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	Groups have been configured with names of mobile browsers.
Available since version	11.1.2
Checkpoints	All checkpoints.

Device: Check if Device is Using Mobile Browser Parameters

The following table summarizes the parameters in the Device: Check if Device is Using Mobile Browser condition.

Table B-50 Device: Check if Device is Using Mobile Browser Parameters

Parameter	Description	Possible Values	Can be Null?
Mobile Browsers Group	Select the group that has a list of mobile browsers	OAAM Mobile Browser Group	No
Default value to return in case of errors	Specify the value to be returned in case of errors.	Boolean. The default is False. True or False	No

Example Usage

This condition is used in the Is Mobile Device rule in the OAAM Base Device ID Policy. It is used to check if the device is using a mobile browser.

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

1. In the Device: Check if device is using Mobile Browser condition, configure the Mobile Browsers Group parameter as OAAM Mobile Browser Group and configure the Default value to return in case of errors parameter as False. The Mobile Browser Group contains names of mobile browsers.

2. Add the Device: Browser header substring condition to the rule with the Substring to check for parameter as OIC.

3. Run authentications from a mobile device using one of the browsers in the Mobile Browser group with browser header substring of OIC, and the Is Mobile Device rule will trigger. Since the OAAM Base Device Policy trigger combination is configured so that if Is Mobile Device returns true, the OAAM Mobile Device ID Policy is run.

For more information on the OAAM Base Device ID policy, see Section 10.6.2, "OAAM Base Device ID Policy."

B.5 Location Conditions

These section provides information on the location conditions.

B.5.1 Location: ASN in Group

General information about the Location: ASN in Group condition is provided in the following table.

Table B-51 Location: ASN in Group

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 be a list of ASNs already defined. You should have this rule configured through a policy.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints except Device ID.

Location: ASN in Group Parameters

The following table summarizes the parameters in the Location: ASN in Group condition.

Table B-52 Location: ASN in Group Parameters

Parameter	Description	Possible Values
Is in group	The parameter controls the outcome of the condition. You can negate the outcome of the condition with this parameter. If the ASN is in the group and the value of this parameter is True, the condition evaluates to True. If the ASN is not in the group and the value of this parameter is False, the condition evaluates to True. In all other cases, the condition evaluates to False.	[True] / False
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 the Group editor in the OAAM Administration Console to edit the ASN group.

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 from these. Or you might not want users to perform a certain activity if they are logging in from an ASN that is from a particular country or region.

For more information on group creation, see Chapter 13, "Managing Groups."

B.5.2 Location: in City Group

General information about the Location: in City Group condition is provided in the following table.

Table B-53 Location: City in Group

Condition	Location: in City Group
Description	Checks whether the current activity belongs to a given city group.
Prerequisites	There should be 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 an IP location database populated.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints except Device ID.

Location: in City Group Parameters

The following table summarizes the parameters in the Location: in City Group condition.

Table B-54 Location: City in Group Parameters

Parameter	Description	Possible Values
Is in group	The parameter controls the outcome of the condition. You can negate the outcome of the condition with this parameter. If the city is in the city group and the value of this parameter is True, the condition evaluates to True. If the city is not in the city group and the value of this parameter is False, the condition evaluates to True. In all other cases, the condition evaluates to False.	[True] / False
City in city group	This is a list of city groups. The Rule's Conditions tab displays a drop-down list of possible groups of cities. Use the Group editor in the OAAM Administration Console to edit this group list.	(java Long values)

Example Usage

Use this condition to determine 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.

For more information on group creation, see Chapter 13, "Managing Groups."

B.5.3 Location: In Carrier Group

General information about the Location: In Carrier Group condition is provided in the following table.

Table B-55 Location: In Carrier Group

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

Location: In Carrier Group Parameters

The following table summarizes the parameters in the Location: In Carrier Group condition.

Table B-56 Location: In Carrier Group Parameters

Parameter	Description	Possible Values
Is in group	The parameter controls the outcome of the condition. You can negate the outcome of the condition with this parameter. If the carrier is in the carrier group and the value of this parameter is True, the condition evaluates to True. If the carrier is not in the carrier group and the value of this parameter is False, the condition evaluates to True. In all other cases, the condition evaluates to False.	[True] / False
IP in carrier group	This is a list of the groups of carriers. The Rule's Condition tab displays drop-down list of possible lists of carriers groups to configure for this parameter. Use the Group editor in the OAAM Administration Console to edit carrier group.

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.

For more information on group creation, see Chapter 13, "Managing Groups."

B.5.4 Location: In Country Group

General information about the Location: In Country Group condition is provided in the following table.

Table B-57 Location: In Country Group

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

Location: In Country Group Parameters

The following table summarizes the parameters in the Location: In Country Group condition.

Table B-58 Location: In Country Group Parameters

Parameters	Description	Possible Value
Is in group	The parameter controls the outcome of the condition. You can negate the outcome of the condition with this parameter. If the IP is in the country group and the value of this parameter is True, the condition evaluates to True. If the IP is not in the country group and the value of this parameter is False, the condition evaluates to True. In all other cases, the condition evaluates to False.	[True] / False
Country in country group	This is a list of group of countries. The Rule's Condition tab will display a drop-down list of possible groups. Use the Group editor in the OAAM Administration Console to edit the group.	(java Long values)

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.

For more information on group creation, see Chapter 13, "Managing Groups."

B.5.5 Location: IP Connection Type in Group

General information about the Location: IP Connection Type in Group condition is provided in the following table.

Table B-59 Location: IP Connection Type in Group

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 be a list of connection types already defined. You should have this rule configured using policies.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints except Device ID.

Location: IP Connection Type in Group Parameters

The following table summarizes the parameters in the Location: IP Connection Type in Group condition.

Table B-60 Location: IP Connection Type in Group

Parameter	Description	Possible Values
Is in group	The parameter controls the outcome of the condition. You can negate the outcome of the condition with this parameter. If the IP's connection type is in the connection type group and the value of this parameter is True, the condition evaluates to True. If the IP's connection type is not in the connection type group and the value of this parameter is False, the condition evaluates to True. In all other cases, the condition evaluates to False.	[True] / False
Connection type in group	This list of connection type groups. The Rule's Condition tab will display a drop-down list of possible lists of connection types. Use the Group editor in administration user interface to edit this group list.

Example Usage

Use the Location: IP Connection Type in Group condition 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."

For more information on group creation, see Chapter 13, "Managing Groups."

B.5.6 Location: IP in Range Group

General information about the Location: IP in Range Group condition is provided in the following table.

Table B-61 Location: IP in Range Group

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 be 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 except Device ID.

Location: IP in Range Group Parameters

The following table summarizes the parameters in the Location: IP in Range Group condition.

Table B-62 Location: IP in Range Group Parameters

Parameter	Description	Possible Values
Is IP in IP-range group	The parameter controls the outcome of the condition. You can negate the outcome of the condition with this parameter. If the IP belongs to one of the IP ranges and the value of this parameter is True, the condition evaluates to True. If the IP does not belong to one of the IP ranges and the value of this parameter is False, the condition evaluates to True. In all other cases, the condition evaluates to False.	[True] / False
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.

Example Usage

The Location: IP in Range Group 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.

For more information on group creation, see Chapter 13, "Managing Groups."

B.5.7 Location: IP Line Speed Type

General information about the Location: IP Line Speed Type condition is provided in the following table.

Table B-63 Location: IP Line Speed Type

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 required for this condition. Most production environments will have an IP location database populated.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints except Device ID.

Location: IP Line Speed Type Parameters

The following table summarizes the parameters in the Location: IP Line Speed Type condition.

Table B-64 Location: IP Line Speed Type Parameters

Parameter	Description	Possible Values
is	The parameter controls the outcome of the condition. You can negate the outcome of the condition with this parameter. If the current IP has a connection line speed as one of the specified connection line speeds and the value of this parameter is True, the condition evaluates to True. If the current IP does not have a connection line speed as one of the connection line speeds and the value of this parameter is False, the condition evaluates to True. In all other cases, the condition evaluates to False.	[True] / False
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

Example Usage

The Location: IP Line Speed Type 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.

B.5.8 Location: IP Maximum Users

General information about the Location: IP Maximum Users condition is provided in the following table.

Table B-65 Location: IP Maximum Users

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	None
Available since version	10.1.4.5
Checkpoints	All checkpoints except Device ID.

Location: IP Maximum Users Parameters

The following table summarizes the parameters in the Location: IP Maximum Users condition.

Table B-66 Location: IP Maximum Users Parameters

Parameter	Description	Possible Values
Seconds elapsed	This is the time period in which the number of users from this IP is to be counted.	integer The default is 300.
The maximum number of users	Maximum number of users allowed.	integer The default is 5.

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.

B.5.9 Location: IP Routing Type in Group

General information about the Location: IP Routing Type in Group condition is provided in the following table.

Table B-67 Location: IP Routing Type in Group

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

Location: IP Routing Type in Group Parameters

The following table summarizes the Location: IP Routing Type in Group parameters in the condition.

Table B-68 Location: IP Routing Type in Group Parameters

Parameter	Description	Possible Values
Is in group	The parameter controls the outcome of the condition. You can negate the outcome of the condition with this parameter. If the IP routing type is in the group and the value of this parameter is True, the condition evaluates to True. If the IP routing type is not in the group and the value of this parameter is False, the condition evaluates to True. In all other cases, the condition evaluates to False.	[True] / False
Routing type in group	This is a list of groups of IP routing types. A drop-down list of possible lists of IP routing type groups. Use the Group editor in the OAAM Administration Console to edit this group list.	(java Long values)

Example Usage

The Location: IP Routing Type in Group 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.

For more information on group creation, see Chapter 13, "Managing Groups."

B.5.10 Location: Is IP from AOL

General information about the Location: Is IP from AOL condition is provided in the following table.

Table B-69 Location: Is IP from AOL

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	None
Available since version	10.1.4.5
Checkpoints	All checkpoints except Device ID.

Location: Is IP from AOL Parameters

The following table summarizes the parameters in the Location: Is IP from AOL condition.

Table B-70 Location: Is IP from AOL Parameters

Parameter	Description	Possible Values	Can be Null?
Is AOL	The parameter controls the outcome of the condition. You can negate the outcome of the condition with this parameter. If the IP is from AOL and the value of this parameter is True, the condition evaluates to True. If the IP is not from AOL and the value of this parameter is False, the condition evaluates to True. In all other cases, the condition evaluates to False.	Boolean [True] / False	No

Example Usage

Use the Location: Is IP from AOL condition to determine 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.

B.5.11 Location: In State Group

General information about the Location: In State Group condition is provided in the following table.

Table B-71 Location: In State Group

Condition	Location: In State Group
Description	Checks whether the country/state of this session belongs to a given country/states group. For example, California belongs to a given states group.
Prerequisites	There should be a group defined already which has states as members. You should have this rule configured in a policy. IP location data is required. Most production environments will have application database populated.
Checkpoints	All checkpoints other than Device ID.

Location: In State Group Parameters

The following table summarizes the Location: In State Group parameters in the condition.

Table B-72 Location: In State Group Parameters

Parameters	Description	Possible Value
Is in group	The parameter controls the outcome of the condition. You can negate the outcome of the condition with this parameter. If the country/state is in the country/state group and the value of this parameter is True, the condition evaluates to True. If the country/state is not in the country/state group and the value of this parameter is False, the condition evaluates to True. In all other cases, the condition evaluates to False.	[True] / False If state is in group is true, trigger this rule. Is state is in group is false, do not trigger.
State in state group	This is a list of group of states. The Rule's Condition tab will display a drop-down list of possible groups. Use the Group editor in the OAAM Administration Console to edit the group.	java Long values

Example Usage

The Location: In State Group condition can be potentially used to determine if the current activity seems to originate from one of several states in the group. If this user comes in from this state, and the state is part of the state group you created, then this condition will be triggered. For example, there are states that do not charge sales tax on purchases, so if you are an online merchant, and if the user comes in from one of these states, then you can bypass your tax calculation rules.

For more information on group creation, see Chapter 13, "Managing Groups."

B.5.12 Location: IP Connection Type

General information about the Location: IP Connection Type condition is provided in the following table.

Table B-73 Location: IP Connection Type

Condition	Location: IP Connection Type
Description	Check connection type for the IP address. Refer to the location.connection.type.enum for connection types. For example: Cable Consumer Satellite Dialup DSL Fixed Wireless Frame Relay ISDN Mobile Wireless Optical Circuit Satellite T1/T3 Connection type is from the geolocation provider. OAAM is prepopulated with connection type enums for the common connection types that the geolocation provides. If the geolocation data provides new connection types, you must configure enums for them.
Prerequisites	There should be a list of connection types already defined. You should have this rule configured using policies.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints except Device ID.

Location: IP Connection Type Parameters

The following table summarizes the parameters in the Location: IP Connection Type condition.

Table B-74 Location: IP Connection Type Parameters

Parameter	Description	Possible Values
Is	The parameter controls the outcome of the condition. You can negate the outcome of the condition with this parameter. If the connection type is the one specified and the value of this parameter is True, the condition evaluates to True. If the connection type is not the one specified and the value of this parameter is False, the condition evaluates to True. In all other cases, the condition evaluates to False.	[True]/ False Checks if the connection type is the specified one and if true, then trigger the condition.
Connection type	This lists connection types to choose from.

Example Usage

Use the Location: IP Connection Type condition to determine whether the IP of the current activity is from a connection type that can be of particular interest to determine fraud. For example, you might have connection type of "satellite link."

B.5.13 Location: IP Maximum Logins

General information about the Location: IP Maximum Logins condition is provided in the following table.

Table B-75 Location: IP Maximum Logins

Condition	Location: IP Maximum Logins
Description	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.
Prerequisites	You should have this rule configured using a policy.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints except Device ID.

Location: IP Maximum Logins Parameters

The following table summarizes the parameters in the Location: IP Maximum Logins condition.

Table B-76 Location: IP Maximum Logins Parameters

Parameter	Description	Possible Values
Authentication status is	Authentication status.	Authentication status is configured through auth.status.enum. For example: Blocked Locked Database Error Password Expired Invalid User Pending Pending activation Session expired Session reused Success System Error User is disabled Wrong answer Wrong password Wrong pin
Seconds elapsed	This is the time period in which the number of logins from this IP is to be counted.	integer The default is 300.
The maximum number of logins	Maximum number of logins for this condition to start triggering	Positive integer. The default is 3.

Example Usage

Use this condition to determine if a particular IP is used by fraudsters to perform logins by using the same login ID. In such cases you see a number of logins from the same IP during a relatively short period. Maximum number of users allowed to log in from a particular IP address is 3 within 300 seconds.

Configure the rule such that if there are more than "x" logins within "y" seconds using the current IP an action may be taken and an alert generated.

B.5.14 Location: IP Excessive Use

General information about the Location: IP Excessive Use condition is provided in the following table.

Table B-77 Location: IP Excessive Use

Condition	Location: IP Excessive Use
Description	Checks to see if this IP is used excessively. Basically, checks to see if a large number of users are using this IP excessively prior than before within a short period (in a few hours) when the IP hadn't been used for "n" number of days.
Prerequisites	You should have this rule configured through a policy.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints except Device ID.

Location: IP Excessive Use Parameters

The following table summarizes the parameters in the Location: IP Excessive Use condition.

Table B-78 Location: IP Excessive Use Parameters

Parameter	Description	Possible Values
Number of users	Number of users logging in from a single IP in a short period.	Positive integers The default is 5 users.
Within (hours)	This parameter defines the short period in which OAAM must find excessive use.	Positive integer The default is 24 hours.
and not used in (days)	This parameter describes the number of days the IP was not in use.	Positive integer The default is not used in 30 days.

Example Usage

Use this condition to monitor IP addresses and check for IP surges within a particular duration when the IP address had not been used in d days. For example, configure a policy and rule to track the number of logins from the same IP address and if there are more than "n" logins in "x" hour from an IP address and the IP address had not been used in "d" days, a high alert should be triggered.

B.5.15 Location: Timed Not Status

General information about the Location: Timed Not Status condition is provided in the following table.

Table B-79 Location: Timed Not Status

Condition	Location: Timed Not Status
Description	Checks the maximum login attempts for all but the given status within the given time period. For example there are n number of attempts from this location, and the authentication is not success in y seconds. You are trying to figure out if there are more than n number of failures in the last five minutes in geolocation (IP).
Prerequisites	You should have this rule configured through a policy.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints except Device ID.

Location: Timed Not Status Parameters

The following table summarizes the parameters in the Location: Timed Not Status condition.

Table B-80 Location: Timed Not Status Parameters

Parameter	Description	Possible Values
Authentication status is not	Authentication status is configured through auth.status.enum. For example: Blocked Locked Database Error Password Expired Invalid User Pending Pending activation Session expired Session reused Success System Error User is disabled Wrong answer Wrong password Wrong pin
within duration (seconds)	This parameter defines the short period in which the number of login attempts that use that location are counted.	Positive integer The default is 300.
for more than	Maximum number of attempts to watch for. If the attempt count exceeds this number, then the condition will evaluate to true.	Positive integer The default is 3.

Example Usage

If there are a number of login attempts from that particular location and the authentication status is not Success, then trigger this rule. This is based on the number of users and not location.

The Location: Timed Not Status condition is generalized for all locations if the defined number of users coming in is more than the number set and the status is the value that has been set, then trigger the rule. For example, if the user is not authenticated and he tries to log in to a particular Web site and the number of user is more than 4 in the duration, then trigger the rule.

Another example: you can use this condition to find out if there were more than 10 attempts from this location where the status is not Success during this time period. A fraudster may have tried to access the system, but he was not successful 10 times. This may be an "alarm" that the location is not good.

This condition can be potentially used to determine if the IP address used in the current activity is compromised. A possible fraud scenario can be detected where a program is used to break the password in an automated manner.

B.5.16 Location: IP in Group

General information about the Location: IP in Group condition is provided in the following table.

Table B-81 Location: IP in Group

Condition	Location: IP in Group
Description	Checks to see if the IP address is in a group of IP addresses.
Prerequisites	There should be a group defined already which has IP addresses as members. You should have this rule configured using a policy. IP location data is required for this condition. Most production environments will have an IP location database populated.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints except Device ID.

Location: IP in Group Parameters

The following table summarizes the parameters in the Location: IP in Group condition.

Table B-82 Location: IP in Group Parameters

Parameter	Description	Possible Values
Is in group	The parameter controls the outcome of the condition. You can negate the outcome of the condition with this parameter. If the IP address is in the group of IP addresses and the value of this parameter is True, the condition evaluates to True. If the IP address is not in the group of IP addresses and the value of this parameter is False, the condition evaluates to True. In all other cases, the condition evaluates to False.	True/ [False]
IP group	This is a list of IP address groups. Use the Group editor in the OAAM Administration Console to edit this group list.

Example Usage

This condition can be potentially used to determine whether the current activity is from a certain IP address. For example, you might have a list of addresses that can monitored and if the current IP of the activity is one of the IP addresses listed in the group, you can configure to take an action or generate an alert.

For more information on group creation, see Chapter 13, "Managing Groups."

B.5.17 Location: Domain in Group

General information about the Location: Domain in Group condition is provided in the following table.

Table B-83 Location: Domain in Group

Condition	Location: Domain in Group
Description	Checks if the second-level domain is in the group of domains. In the Domain Name System (DNS) hierarchy, a second-level domain (SLD) is a domain that is directly below a top-level domain (TLD). Second-level domains commonly refer to the organization that registered the domain name.
Prerequisites	A group must be defined already which has second-level domains as members. You should have this rule configured using a policy. Internet Protocol address (IP address) location data is required for this condition. Most production environments will have an IP location database populated.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints except Device ID.

Location: Domain in Group Parameters

The following table summarizes the parameters in the Location: Domain in Group condition.

Table B-84 Location: Domain in Group Parameters

Parameter	Description	Possible Values
Is in group	The parameter controls the outcome of the condition. You can negate the outcome of the condition with this parameter. If the second-level domain is in the group of second-level domains and the value of this parameter is True, the condition evaluates to True. If the second-level domain is not in the group of second-level domains and the value of this parameter is False, the condition evaluates to True. In all other cases, the condition evaluates to False.	[True] / False
Second level Domain in group	This is a list of groups that contain second-level domain names. The Conditions tab of the rule displays a drop-down list of groups that contains second-level domain names. Use second-level domain names to pass and block entire sites such as *.example.org or entire intranet levels such as *.sales.* or *.admin.* Use the Group editor in the OAAM Administration Console to edit this group list.	(java Long values)

Example Usage

Use this condition to determine if the current activity seems to originate from one of the second-level domains of interest. For example you might have a list of second-level domain groups and if the current IP used for the activity belongs to one of those second-level domains, you can configure the system to take an action or generate an alert.

For more information on group creation, see Chapter 13, "Managing Groups."

B.5.18 Location: IP Connection Speed in Group

General information about the Location: IP Connection Speed in Group condition is provided in the following table.

Table B-85 Location: IP Connection Speed in Group

Condition	Location: IP Connection Speed in Group
Description	Checks if the IP connection speed is in the group. Internet connection speed is categorized into High, Medium, Low or Unknown. high: A user connecting to the Internet through OCX, TX, and Framerelay medium: A user connecting to the Internet through Satellite, DSL, Cable, Fixed Wireless, and ISDN low: A user connecting to the Internet through Dialup and Mobile Wireless unknown: Quova/Neustar was unable to obtain any line speed information
Prerequisites	There should be a group defined already which has IP connection speeds as members. You should have this rule configured using a policy. IP location data is required for this condition. Most production environments will have an IP location database populated.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints except Device ID.

Location: IP Connection Speed in Group Parameters

The following table summarizes the parameters in the Location: IP Connection Speed in Group condition.

Table B-86 Location: IP Connection Speed in Group Parameters

Parameter	Description	Possible Values
Is in group	The parameter controls the outcome of the condition. You can negate the outcome of the condition with this parameter. If the IP connection speed is in the IP connection speed group and the value of this parameter is True, the condition evaluates to True. If the IP connection speed is not in the IP connection speed group and the value of this parameter is False, the condition evaluates to True. In all other cases, the condition evaluates to False.	[True] / False
Connection speed in group	This is a list of connection speeds. The Rule's Conditions tab displays a drop-down list of possible groups of connection speeds. Use the Group editor in the OAAM Administration Console to edit this group list.	(java Long values)

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. For example, you may want an alert generated if the speed is high for the user who usually logs in from a dial-up network.

For more information on group creation, see Chapter 13, "Managing Groups."

B.5.19 Location: ISP in Group

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

Table B-87 Location: ISP in Group

Condition	Location: ISP in Group
Description	Checks if the ISP for the current IP address is (or is not) in the ISP group. This group contains Internet Service Providers. Examples of ISPs are Comcast, Verizon, AOL, and so on.
Prerequisites	There should be a list of ISP groups already defined. You should have this rule configured using policies.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints except Device ID.

Location: ISP in Group Parameters

The following table summarizes the parameters in the Location: ISP in Group condition.

Table B-88 Location: ISP in Group Parameters

Parameter	Description	Possible Values
Is in group	The parameter controls the outcome of the condition. You can negate the outcome of the condition with this parameter. If the ISP is in the ISP group and the value of this parameter is True, the condition evaluates to True. If the ISP is not in the ISP group and the value of this parameter is False, the condition evaluates to True. In all other cases, the condition evaluates to False.	[True] / False
ISP in ISP group	This list of ISP groups. The Rule's Condition tab will display a drop-down list of possible lists of ISP groups. Use the Group editor in administration user interface to edit this group list.

Example Usage

Use this condition to determine whether the ISP of the current activity comes from an ISP that can be of particular interest to determine fraud. For example, in the Pre-authentication Policy rule, Blacklist ISPs, the ISP group is OAAM Restricted ISPs. The action is to OAAM Block and the Alert is OAAM Restricted ISP.

For more information on group creation, see Chapter 13, "Managing Groups."

B.5.20 Location: Top-Level Domain in Group

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

Table B-89 Location: Top Level Domain in Group

Condition	Location: Top Level Domain in Group
Description	Checks if the Top Level Domain is in the group. This group contains top-level domain names (the last part of an Internet domain name, that is, the letters that follow the final dot of any domain name). Use top-level domain names to pass and block whole countries, for example,.uk, .ru, or .ca, and entire communities, for example, .mil, .info, .gov, or edu.
Prerequisites	A group must be defined already which has top-level domains as members. You should have this rule configured using a policy. Internet Protocol address (IP address) location data is required for this condition. Most production environments will have an IP location database populated.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints except Device ID.

Location: Top Level Domain in Group Parameters

The following table summarizes the parameters in the Location: Top Level Domain in Group condition.

Table B-90 Location: Top Level Domain in Group Parameters

Parameter	Description	Possible Values
Is in group	The parameter controls the outcome of the condition. You can negate the outcome of the condition with this parameter. If the top-level domain is in the group of top-level domain names and the value of this parameter is True, the condition evaluates to True. If the top-level domain is not in the group of top-level domain names and the value of this parameter is False, the condition evaluates to True. In all other cases, the condition evaluates to False.	[True] / False
Top level Domain in group	This is a list of groups that contain top-level domain names. The Conditions tab of the rule displays a drop-down list of groups that contains top-level domain names. Use top-level domain names to pass and block entire sites such as *.example.org or entire intranet levels such as *.sales.* or *.admin.* Use the Group editor in the OAAM Administration Console to edit this group list.	(java Long values)

For more information on group creation, see Chapter 13, "Managing Groups." You must enter values when creating the domain groups.

Example Usage

Use this condition to determine if the current activity seems to originate from one of the top-level domains of interest. For example you might have a list of top-level domain groups and if the current IP used for the activity belongs to one of those top-level domains, you can configure the system to take an action or generate an alert.

For more information on group creation, see Chapter 13, "Managing Groups."

B.5.21 Location: IP Multiple Devices

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

Table B-91 Location: IP Multiple Devices

Condition	Location: IP Multiple Devices
Description	Checks for the maximum number of devices from the IP address within the given time duration
Prerequisites	You should have this rule configured using a policy. IP location data is required for this condition. Most production environments will have an IP location database populated.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints except Device ID.

Location: IP Multiple Devices Parameters

The following table summarizes the parameters in the Location: IP Multiple Devices condition.

Table B-92 Location: IP Multiple Devices Parameters

Parameter	Description	Possible Values
Authentication status is	Authentication status is configured through auth.status.enum. For example: Blocked Locked Database Error Password Expired Invalid User Pending Pending activation Session expired Session reused Success System Error User is disabled Wrong answer Wrong password Wrong pin
Duration	This is the time period in which the number of devices from this IP is to be counted.	The default is 300.
Time	The time value.
for more than	Maximum number of devices to watch for. If the device count exceeds this number, then the condition will evaluate to true.	The default is 3.

B.5.22 Location: IP Routing Type

General information about the Location: IP Routing Type condition is provided in the following table.

Table B-93 Location: IP Routing Type

Condition	Location: IP Routing Type
Description	Check 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
Prerequisites	You should have this rule configured using policies.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints except Device ID

Location: IP Routing Type Parameters

The following table summarizes the parameters in the Location: IP Routing Type condition.

Table B-94 Location: IP Routing Type Parameters

Parameter	Description	Possible Values	Can be Null?
Is	The parameter controls the outcome of the condition. You can negate the outcome of the condition with this parameter. If the routing type is the one specified and the value of this parameter is True, the condition evaluates to True. If the routing type is not the one specified and the value of this parameter is False, the condition evaluates to True. In all other cases, the condition evaluates to False.	[True]/ False	No
Routing type	This lists routing types to choose from.		No

Example Usage

Use this condition to determine whether the IP of the current activity uses a routing type that can be of particular interest to determine fraud.

Sometimes you might not want to perform a task if the IP is unknown or private.

B.5.23 Location: IP Type

General information about the Location: IP Type condition is provided in the following table.

Table B-95 Location: IP Type

Condition	Location: IP Type
Description	Checks to see if IP type is one of the following values: valid, unknown, or private.
Prerequisites	IP location data is required for this condition. Most production environments will have an IP location database populated.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints except Device ID.

Location: IP Type Parameters

The following table summarizes the parameters in the Location: IP Type condition.

Table B-96 Location: IP Type Parameters

Parameter	Description	Possible Values
IP type	This is a single IP location type value. If you need to check for multiple IP location types, you will need multiple conditions. The IP location type is a single valid from the enum, location.ip.type.enum.
Is	This is a boolean parameter that defines a default return value if the IP is valid, unknown, or private.	True/ [False]

Example Usage

If you want to check for an IP type, valid, private, or unknown, then use this condition.

B.5.24 Location: User Status Count

General information about the Location: User Status Count condition is provided in the following table.

Table B-97 Location: User Status Count

Condition	Location: User Status Count
Description	Check the number of times users are allowed with this status during the specified duration
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints except Device ID.

Location: User Status Count Parameters

The following table summarizes the parameters in the Location: User Status Count condition.

Table B-98 Location: User Status Count Parameters

Parameter	Description	Possible Values
Within	Number of time units to look back in history	Positive Integer. The default is 3.
Time unit	Time unit to be associated with the "Within" parameter	Select a time unit configured from the time.unit.enum property: Milliseconds, Seconds, Minutes, Hours, Days, Weeks, Months, Years
Maximum number of users allowed	Maximum number of users allowed for this condition to start triggering	Positive Integer The default is 3.
With Status	Name of the group that is of type auth status.	Long. ID of the group

Example Usage

Determine if too many users have logins from the logins that failed from the IP in the last n hours.

B.6 Session Conditions

The Session conditions are documented in this section.

B.6.1 Session: Check Parameter Value

General information about the Session: Check Parameter Value condition is provided in the following table.

Table B-99 Session: Check Parameter Value

Condition	Session: Check Parameter Value
Description	Check to see whether the specified parameter value is above the given threshold. Use this condition to determine whether the value of a particular parameter in the transaction is above a known threshold and then actions can be taken accordingly. Basically provided a mathematical function for integrators. This will be useful in native integration.
Prerequisites	None for the 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 Checkpoints.

B.6.1.1 Session: Check Parameter Value Parameters

The following table summarizes the parameters in the Session: Check Parameter Value condition.

Table B-100 Session: Check Parameter Value Parameters

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
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 "creditcard" and whose value at Checkpoint is 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
Value above	This is basically the threshold value. Use this parameter 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 parameter value.	Long values	Yes

B.6.1.2 Example Usage

Use this condition when you want to determine whether the value of a particular attribute of the transaction exceeds a 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 Parameter Key of your transaction to purchase.orderTotal assuming that you have such an attribute in your transaction.

2. Configure Value above 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.

B.6.2 Session: Check Parameter Value in Group

General information about the Session: Check Parameter Value in Group condition is provided in the following table.

Table B-101 Session: Check Parameter Value in Group

Condition	Session: Check Parameter 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 the 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.

Session: Check Parameter Value in Group Parameters

The following table summarizes the parameters in the Session: Check Parameter Value in Group condition.

Table B-102 Session: Check Parameter Value in Group Parameters

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 a part of the value of a particular attribute of the transaction matches a 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.

For more information on group creation, see Chapter 13, "Managing Groups."

B.6.3 Session: Check Parameter Value for Regular Expression

General information about the Session: Check Parameter Value for Regular Expression condition is provided in the following table.

Table B-103 Session: Check Parameter Value for Regular Expression

Condition	Session: Check Parameter Value for Regular Expression
Description	Determine whether the specified parameter value matches regular expression. Use this condition 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 the 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 Checkpoints.

B.6.3.1 Session: Check Parameter Value for Regular Expression Parameters

The following table summarizes the parameters in the Session: Check Parameter Value for Regular Expression condition.

Table B-104 Session: Check Parameter Value for Regular Expression Parameters

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
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 "creditcard" and whose value at Checkpoint is 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 "Parameter Key". 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

B.6.3.2 Example Usage

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

For example, you configured a transaction called "purchase" and want to trigger a rule whenever the customer e-mail 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 "Parameter Key" of your transaction to "customer.e-mail" assuming that you have such an 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 e-mail addresses ending with ".gov" or ".mil".

5. Verify that the alert is generated.

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

   Notice that alert is not generated.

B.6.4 Session: Check Two String Parameter Values

General information about the Session: Check Two String Parameter Values condition is provided in the following table.

Table B-105 Session: Check Two String Parameter Values

Condition	Session: Check Two String Parameter Value
Description	Check to see whether the specified parameter value is equal to a given character string. Use this condition 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 the 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 Checkpoints.

Session: Check Two String Parameter Values Parameters

The following table summarizes the parameters in the Session: Check Two String Parameter Values condition.

Table B-106 Session: Check Two String Parameter Values Parameters

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 "creditCardType" and whose value at Checkpoint is to be populated by users credit card type, then key is "creditCardType" in this case.		Yes
Value	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 "Parameter Key" of your transaction to "purchase.creditCardType" assuming that you have such an attribute in your transaction.

2. Configure "Value" to "A_CARD". Configure an alert that says "A_CARD Used"

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

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

B.6.5 Session: Check String Value

General information about the Session: Check String Value condition is provided in the following table.

Table B-107 Session: Check String Value

Condition	Session: Check String Value
Description	Check to see whether the specified parameter value is equal to a given character string. Use this condition 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 the 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.

B.6.5.1 Session: Check String Value Parameters

The following table summarizes the parameters in the Session: Check String Value condition.

Table B-108 Session: Check String Value Parameters

Parameter	Description	Possible Value	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 "creditCardType" and whose value at Checkpoint is 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

B.6.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 "Parameter Key" of your transaction to "purchase.creditCardType" assuming that you have such an attribute in your transaction.

2. Configure "Value" to "A_CARD". Configure an alert that says "A_CARD Used"

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

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

B.6.6 Session: Time Unit Condition

General information about the Session: Time Unit condition is provided in the following table.

Table B-109 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.

Session: Time Unit Parameters

The following table summarizes the parameters in the Session: Time Unit condition.

Table B-110 Day of Week Parameters

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-delimited values when using IN or NOT in operator. If comma-delimited 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 True or False Default value is True. The "Is Condition True" parameter controls the outcome of the condition. You can negate the outcome of the condition with this parameter. If the comparison is True and the value of this parameter is True, the condition evaluates to True. If the comparison is False and the value of this parameter is False, the condition evaluates to True. In all other cases, the condition evaluates to False.
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"

B.6.7 Session: Compare Two Parameter Values

General information about the Session: Compare Two Parameter Values condition is provided in the following table.

Table B-111 Session: Compare Two Parameter Values

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. Use this condition to check if the value of a particular parameter in the transaction is above / below / equal to another parameter. Basically provided a 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

Session: Compare Two Parameter Values Parameters

The following table summarizes the parameters in the Session: Compare Two Parameter Values condition.

Table B-112 Session: Compare Two Parameter Values Parameters

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 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 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 obtaining the parameters or if one of both of the parameters 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 must use this rule with this condition.

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

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

3. Configure Compare Operator 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.

B.6.8 Session: Check Current Session Using the Filter Conditions

General information about the Session: Check Current Session Using the Filter Conditions condition is provided in the following table.

Table B-113 Session: Check Current Session Using the Filter Conditions

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 obtain 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 the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions
Available since version	11.1.2.0.0
Checkpoints	All Checkpoints except Device ID.

Session: Check Current Session Using the Filter Conditions Parameters

The following table summarizes the parameters in the Session: Check Current Session Using the Filter Conditions condition.

Table B-114 Session: Check Current Session Using the Filter Conditions Parameters

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 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 obtain 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 must use 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 the Mozilla web browser, and the rule triggers.

4. Perform logins from the same IP address with the other web browser, such as Internet Explorer of Safari, and the rule does not trigger.

B.6.9 Session: Check Risk Score Classification

General information about the Session: Check Risk Score Classification condition is provided in the following table.

Table B-115 Session: Check Risk Score Classification

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

Session: Check Risk Score Classification Parameters

The following table summarizes the parameters in the Session: Check Risk Score Classification condition.

Table B-116 Session: Check Risk Score Classification Parameters

Parameter	Description	Possible Values	Can be Null?
Classification Type	Type or Range of risk score. Out of box risk score classified in three types or ranges. (low is 0 to 0, medium is 1 to 500, high is 501 to 1000). Note: you can change the default values or add more classifications using the following enum: oracle.oaam.common.rules.riskscore.classification.enum	(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 must 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.

B.6.10 Session: Cookie Mismatch

General information about the Session: Cookie Mismatch condition is provided in the following table.

Table B-117 Session: Cookie Mismatch

Condition	Session: Cookie Mismatch
Description	Checks to see if there is mismatch of supplied cookie with the expected cookie.
Prerequisites	None for the 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 except Device ID.

Session: Cookie Mismatch Parameters

The following table summarizes the parameters in the Session: Cookie Mismatch condition.

Table B-118 Session: Cookie Mismatch Parameters

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.

B.6.11 Session: Mismatch in Browser Fingerprint

General information about the Session: Mismatch in Browser Fingerprint condition is provided in the following table.

Table B-119 Session: Mismatch in Browser Fingerprint

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 for the 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 except Device ID.

Session: Mismatch in Browser Fingerprint Parameters

The following table summarizes the parameters in the Session: Mismatch in Browser Fingerprint condition.

Table B-120 Session: Mismatch in Browser Fingerprint Parameters

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 a simulator or browser modifier extensions to send the desired user agent strings.

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

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

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

The rule should trigger.

B.6.12 Session: Compare with Current Date Time

General information about the Session: Compare with Current Date Time condition is provided in the following table.

Table B-121 Session: Compare with Current Date Time

Condition	Session: Compare with current date time
Description	Compare specified parameter value with current time
Prerequisites	None for the 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.

Session: Compare with Current Date Time Parameters

The following table summarizes the parameters in the Session: Compare with Current Date Time condition.

Table B-122 Session: Compare with Current Date Time Parameters

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 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 must:

1. Use this rule with this condition.

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

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

4. Configure If given date key returns empty to false

5. Process a few transaction by providing different po_date values.

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

B.6.13 Session: IP Changed

General information about the Session: IP Changed condition is provided in the following table.

Table B-123 Session: IP Changed

Condition	Session: IP Changed
Description	IP Address is changed since transaction is started
Prerequisites	None for the 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

Session: IP Changed Parameters

The following table summarizes the parameters in the Session: IP Changed condition.

Table B-124 Session: IP Changed Parameters

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 must use this rule with this condition.

Configure the "IP Key" of your transaction as "purchase.ip_addr" assuming that you have such an 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.

B.6.14 Session: Check Value in Comma Separated Values

General information about the Session: Check Value in Comma Separated Values condition is provided in the following table.

Table B-125 Session: Check Value in Comma Separated Values

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 the 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

Session: Check Value in Comma Separated Values Parameters

The following table summarizes the parameters in the Session: Check Value in Comma Separated Values condition.

Table B-126 Session: Check Value in Comma Separated Values Parameters

Parameter	Description	Possible Values	Can be Null?
Parameter 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
Is True	The parameter controls the outcome of the condition. You can negate the outcome of the condition with this parameter. If the value of the key is in the list and the value of this parameter is True, the condition evaluates to True. If the value of the key is not in the list and the value of this parameter is False, the condition evaluates to True. In all other cases, the condition evaluates to False.	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-delimited 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 "Parameter Key" of your transaction as "countries_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-delimited list of countries resided contains "US" the rule will trigger.

B.7 System Conditions

The system conditions are documented in this section.

B.7.1 System - Check Boolean Property

General information about the System - Check Boolean Property condition is provided in the following table.

Table B-127 System - Check Boolean Property

Condition	System - Check Boolean Property
Description	Verify if specified property equals true of false.
Prerequisites	None for the 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 checkpoints.

B.7.1.1 System - Check Boolean Property Parameters

The following table summarizes the parameters in the System - Check Boolean Property condition.

Table B-128 System - Check Boolean Property Parameters

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

B.7.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 a 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.

B.7.2 System - Check Enough Pattern Data

General information about the System - Check Enough Pattern Data condition is provided in the following table.

Table B-129 System - Check enough pattern data

Details	System - Check Enough Pattern Data
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 the 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.

System - Check Enough Pattern Data Parameters

The following table summarizes the parameters in the System - Check Enough Pattern Data condition.

Table B-130 System - Check enough pattern data parameters

Parameter	Description	Possible Values	Can be null?
Pattern name to check for data	Name of the pattern for which the data availability is to be checked.	Pattern names from drop down list	No
Number of days of data	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
Is pattern data available	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. Use this parameter to decide the outcome of the condition.	[True] / False	Yes
Return value if condition encounters an error	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 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.

B.7.3 System - Check If Enough Data is Available for Any Pattern

General information about the System - Check If Enough Data is Available for Any Pattern condition is provided in the following table.

Table B-131 System - Check If Enough Data is Available for Any Pattern

Details	System - Check If Enough Data is Available for Any Pattern
Condition	Checks if enough profiling data is available for any pattern. This condition will check if pattern data is available in the system for last several days.
Description	This condition will check 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 standard policies use this rule to determine if there is enough pattern data captured to start running pattern based risk analysis.
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	Autolearning 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.

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

The following table summarizes the parameters in the System - Check If Enough Data is Available for Any Pattern condition.

Table B-132 System - Check If Enough Data is Available for Any Pattern Parameters

Parameter	Description	Possible Value	Can be Null?
Number of days of data	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
Is pattern data available	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. Use this parameter to decide the outcome of the condition.	[True] / False	Yes
Return value if condition encounters an error	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 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.

B.7.4 System - Check Integer Property

General information about the System - Check Integer Property condition is provided in the following table.

Table B-133 System - Check Integer Property

Condition	System - Check Integer Property
Description	Verify if specified property equals expected integer value
Prerequisites	None for the 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 checkpoints.

System - Check Integer Property Parameters

The following table summarizes the parameters in the System - Check Integer Property condition.

Table B-134 System - Check Integer Property Parameters

Parameter	Description	Possible Value	Can be Null?
Property	The complete name of the property that must be checked.		Yes
Value	The expected value of the property. If the property has this value then the condition will evaluate to true.	Integer	Yes
default value (if null)	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 a 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 Value to 25.

2. Configure default value (if null) to 30.

3. Run authentication users to see the rule trigger.

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.

B.7.5 System - Check Request Date

General information about the System - Check Request Date condition is provided in the following table.

Table B-135 System - Check Request Date

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 the 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 Checkpoints.

System - Check Request Date Parameters

The following table summarizes the parameters in the System - Check Request Date condition.

Table B-136 System - Check Request Date Parameters

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, the rule is triggered if date entered is > today, the rule is not triggered Case B Set parameter to true if date entered is < today, the rule is not triggered if date entered is > today, the rule 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.

B.7.6 System - Check String Property

General information about the System - Check String Property condition is provided in the following table.

Table B-137 System - Check String Property

Condition	System - Check String Property
Description	Verify if specified property equals expected string value
Prerequisites	None for the 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 Checkpoints.

System - Check String Property Parameters

The following table summarizes the parameters in the System - Check String Property condition.

Table B-138 System - Check String Property Parameters

Parameter	Description	Possible Value	Can be Null?
Property	The complete name of the property that must be checked.		Yes
Value	The expected value of the property. If the property has this value then the condition will evaluate to true.	String	Yes
default value (if null)	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 Property to trigger.sample.rule.test.string.

2. Configure Value to test_string and configure default value (if null) 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 a completely different string value.

5. Run authentication on users again.

   The rule does not trigger.

B.8 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.

B.8.1 About Duration Types

You may need to specify a duration type in some of the Transaction conditions. This section describes the "rolling" and "calendar" duration types.

Duration Types: Rolling

In Transaction conditions, if you specify the duration type as rolling, the following property controls how the date/time for the start point is calculated:

tracker.transaction.condition.computeDuration.useSystemTime

If you set the property to true

If the property is set to true, OAAM takes the current system time as the end point to count backward to the start point. This property is set to true by default and calculates system time. When the duration is described as "last" x seconds/minutes/hours/days, use the rolling type duration. For example, if you specify 1 day using the rolling duration type, the rolling day starts 24 hours (exactly 1 day) from the current system 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. If you specify 1 hour using rolling duration type, it simply subtracts 60 minutes from the current time to compute the start time of the duration window.

Examples of the rolling duration type are as follows:

A "rolling" week starts 7 days from the current day.

A "rolling" month starts from the same day of the previous month.

A "rolling" year starts from the same day of the previous year.

When you specify the rolling duration type, the end date/time is the current time. The duration type affects how the start time of the duration is computed.

If you set the property to false

If the property is set to false, OAAM takes the last transaction time as the end point to count backward to the start point. For example, if you specify 1 day using the rolling duration type, the rolling day starts 24 hours (exactly 1 day) from the last transaction time.

The tracker.transaction.condition.computeDuration.useSystemTime property fixes Bug 12960845 for online (real-time) transaction processing. For offline execution, it is mandatory to set this property to false so that OAAM will use the last transaction time instead of current system time.

Before/Skip Option

If tracker.transaction.condition.computeDuration.useSystemTime is set to True:

The Before/Skip configuration is useful for rule requirements such as the following:

The rule checks transactions to see whether or not the Transaction Type has been used by the user in the last 6 months excluding the last 7 days?" If yes, the transaction type has been used by the user, then allow the user to perform the transaction. If no, the transaction type has not been used by the user, then challenge the user. If the rule execution was on 12/Dec/2014 at 11:00:00 am for the online scenario, the rule would check for the duration from 05/Jun/2014 11:00:00 am to 05/Dec/2014 11:00:00 am.

If tracker.transaction.condition.computeDuration.useSystemTime is set to False:

Consider the same rule requirement for offline scenario where rule is executed for the transaction/session of 12/Dec/2014 11:00:00am at some time later than the transaction/session time. For example, OAAM Offline can be loading/running rules for the session/transaction at 20/Dec/2014 05:00:00am. In this scenario, OAAM Offline would consider the transaction/session time as 12/Dec/2014 11:00:00am and not 20/Dec/2014 05:00:00am.

Duration Types: Calendar

There will be occasions where you want to specify the duration window to start at 0.00. For those occasions, use the duration type as "calendar".

Therefore, if you specify 1 day using "calendar" as the duration type, the "calendar" day starts at 0.00 (12:00 am) of that day and ends at the current time.

For example, suppose the current time is 3.35pm and you want to count behavior that occurred between 3pm and 3.35 pm then you can specify it has 1 hour with duration type as 'calendar'.

Examples of the calendar duration type are as follows:

• A "calendar" week starts from Sunday regardless of the current day.

• A "calendar" month starts from the 1st of the current month.

• A "calendar" year starts from January 1st of the current year.

When you specify the "calendar" duration type, the end date/time is the current time. The duration type affects how the start time 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. For example, if today is February 6, and you want to look at data from January 17 to the 23rd, you would specify "Before" 15 days.

B.8.2 Transaction: Check Count of Any Entity or Element of a Transaction Using Filter Conditions

General information about the Transaction: Check Count of Any Entity or Element of a Transaction Using Filter Conditions condition is provided in the following table.

Table B-139 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
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.

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

The following table summarizes the parameters in the Transaction: Check Count of Any Entity or Element of a Transaction Using Filter Conditions condition.

Table B-140 Transaction: Check Count of Any Entity or Element of a Transaction Using Filter Conditions Parameters

Parameter	Description	Possible Values	Can be Null?
Select Transaction to check	Transaction Definition fully qualified key. This is specified using list box that has list of transaction definitions		No
Select Entity or Element to count	Transaction Entity/Element that must be counted for checking		No
Specified Condition For Count	Condition for the count check. Select only valid operators that are relevant to numeric values		No
Specified Check Value for Count	Count value to check. Specify only valid positive integers.		No
Duration	Duration Descriptor. For information on Duration Types, see Section B.8.1, "About Duration Types."		No
Ignore Current Transaction in count?	Flag to indicate if the current transaction must be ignored in the count
for the same user?	Boolean flag to indicate whether only transactions belonging to the current user to be counted or not		Yes
Apply the filter checks on Current Transaction?	Flag to indicate if the filter conditions have to validated on current transaction before doing the count		No
Filter Key 1 Filter Key 2 Filter Key 3 Filter Key 4 Filter Key 5 Filter Key 6	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
Filter Condition 1 Filter Condition 2 Filter Condition 3 Filter Condition 4 Filter Condition 5 Filter Condition 6	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 must 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.

B.8.3 Transaction: Check Current Transaction Using Filter Condition

General information about the Transaction: Check Current Transaction Using Filter condition is provided in the following table.

Table B-141 Transaction: Check Current Transaction Using Filter

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.

Transaction: Check Current Transaction Using Filter Parameters

The following table summarizes the parameters in the Transaction: Check Current Transaction Using Filter condition.

Table B-142 Transaction: Check Current Transaction Using Filter Parameters

Parameter	Description	Possible Values	Can be Null?
Select Transaction to check	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
Filter Key 1 Filter Key 2 Filter Key 3 Filter Key 4 Filter Key 5 Filter Key 6	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
Filter Condition 1 Filter Condition 2 Filter Condition 3 Filter Condition 4 Filter Condition 5 Filter Condition 6	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 must 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.

You can use this condition to specify up to six (6) filter conditions on the current transaction.

B.8.4 Transaction: Check if Consecutive Transactions in Given Duration Satisfy the Filter Conditions

General information about the Transaction: Check if Consecutive Transactions in Given Duration Satisfy the Filter Conditions condition is provided in the following table.

Table B-143 Transaction: Check if Consecutive Transactions in Given Duration Satisfy the Filter Conditions

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.

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

The following table summarizes the parameters in the Transaction: Check if Consecutive Transactions in Given Duration Satisfy the Filter Conditions condition.

Table B-144 Transaction: Check if Consecutive Transactions in Given Duration Satisfy the Filter Conditions Parameters

Parameter	Description	Possible Values	Can be Null?
Select Transaction to check	Transaction Definition fully qualified key. This is specified using list box that has list of transaction definitions		No
Duration	Duration Descriptor. For information on Duration Types, see Section B.8.1, "About Duration Types."		No
Select transaction Status Group	Group of Transaction Statuses that should be considered. If no group is specified then Transaction Status is ignored in the query.		Yes
Ignore Current Transaction in count?	Flag to indicate if the current transaction must be ignored
for the same user?	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
Allow gaps in transactions during checks?	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
No of transactions to check for 1st set of conditions	Number of transactions that should satisfy the 1st check. Specify positive integers.		No
Filter Key 101 Filter Key 102 Filter Key 103 Filter Key 104 Filter Key 105 Filter Key 106	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
Filter Condition 101 Filter Condition 102 Filter Condition 103 Filter Condition 104 Filter Condition 105 Filter Condition 106	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 must be specified
No of transactions to check for 2nd set of conditions	Number of transactions that should satisfy the 2nd check. Specify positive integers.		No
Filter Key 201 Filter Key 202 Filter Key 203 Filter Key 204 Filter Key 205 Filter Key 206	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.
Filter Condition 201 Filter Condition 202 Filter Condition 203 Filter Condition 204 Filter Condition 205 Filter Condition 206	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 must 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.

B.8.5 Transaction: Check Number of Times Entity Used in Transaction

General information about the Transaction: Check Number of Times Entity Used in Transaction condition is provided in the following table.

Table B-145 Transaction: Check Number of Times Entity Used in Transaction

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.

Transaction: Check Number of Times Entity Used in Transaction Parameters

The following table summarizes the parameters in the Transaction: Check Number of Times Entity Used in Transaction condition.

Table B-146 Transaction: Check Number of Times Entity Used in Transaction Parameters

Parameter	Description	Possible Values	Can be Null?
Select Transaction to check	Transaction Definition fully qualified key. This is specified using list box that has list of transaction definitions		No
Select Transaction Entity to count	Select the entity/element to be counted. Only distinct values will be counted		No
Specified Condition	Specified Condition		No
Specified Count	Count value to check. Specify only valid positive integers.		No
Duration	Specify the duration during which the transactions must be counted. Duration descriptor widget renders the user interface for specifying the duration. For information on Duration Types, see Section B.8.1, "About Duration Types."		No
Transaction Status	Specify the transaction status that must be considered for counting. If you want to consider all transactions regardless of their status then don't specify any status		Yes
Ignore Current Transaction in count?	Flag to indicate if the current transaction must 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.

B.8.6 Transaction: Check Transaction Aggregrate and Count Using Filter Conditions

General information about the Transaction: Check Transaction Aggregrate and Count Using Filter Conditions condition is provided in the following table.

Table B-147 Transaction: Check Number of Times Entity Used in Transaction

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.

Transaction: Check Transaction Aggregrate and Count Using Filter Conditions Parameters

The following table summarizes the parameters in the Transaction: Check Transaction Aggregrate and Count Using Filter Conditions condition.

Table B-148 Transaction: Check Transaction Aggregrate and Count Using Filter Parameters

Parameter	Description	Possible Values	Can be Null?
Select Transaction to check	Transaction Definition fully qualified key. This is specified using list box that has list of transaction definitions		No
Select the aggregate function	Aggregrate function to check. Available functions are sum, min, max, avg
Select Entity or Element to count	Numeric element on which aggregrate check must 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
Specified Condition for Aggregate	Operator to be applied for the aggregrate condition. Specify greater than, greater than or equals, less than, less than or equals		No
Specified Check Value for Aggregate	Aggregrate numeric value to check		No
Specified Condition For Count	Operator to be applied for the count condition. Specify greater than, greater than or equals, less than, less than or equals		Yes
Specified Check Value for Count	Transaction count numeric value to check		Yes
Duration	Specify the duration during which the transactions must be counted. The duration descriptor enables you to specify the duration.		No
Transaction Status	Specify the transaction status that must be considered for counting. If you want to consider all transactions regardless of their status, do not specify any status		Yes
Ignore Current Transaction in count?	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
for the same user?	Boolean flag to indicate whether only transactions belonging to the current user to be counted or not		Yes
Apply the filter checks on Current Transaction	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.
Filter Key 1 Filter Key 2 Filter Key 3 Filter Key 4 Filter Key 5 Filter Key 6	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.
Filter Condition 1 Filter Condition 2 Filter Condition 3 Filter Condition 4 Filter Condition 5 Filter Condition 6	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 must 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 duration type 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 the filter checks on Current Transaction.

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

You can use this condition to specify up to six (6) filter conditions that are applied on transactions that are considered for counting

B.8.7 Transaction: Check Transaction Count Using Filter Condition

General information about the Transaction: Check Transaction Count Using Filter condition is provided in the following table.

Table B-149 System - Check String Property Parameters

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.

Transaction: Check Transaction Count Using Filter Parameters

The following table summarizes the parameters in the Transaction: Check Transaction Count Using Filter condition.

Table B-150 Transaction: Check Transaction Count Using Filter Parameters

Parameter	Description	Possible Values	Can be Null?
Select Transaction to count	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
Specified Condition For Count	Operator to be applied for the count condition. Specify greater than, greater than or equals, less than, less than or equals		No
Specified Check Value for Count	Transaction count numeric value to check		No
Duration	Specify the duration during which the transactions must be counted. The duration descriptor enables you to specify the duration.		No
Transaction Status	Specify the transaction status that must be considered for counting. Do not specify any status if you want to consider all transactions regardless of their status.		Yes
Ignore Current Transaction in count?	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
for the same user?	Boolean flag to indicate whether only transactions belonging to the current user to be counted or not		Yes
Apply the filter checks on Current Transaction?	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.
Filter Key 1 Filter Key 2 Filter Key 3 Filter Key 4 Filter Key 5 Filter Key 6	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
Filter Condition 1 Filter Condition 2 Filter Condition 3 Filter Condition 4 Filter Condition 5 Filter Condition 6	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 must 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 large number 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 Specified Condition For Count as Greater Than Equals.

2. Specify Count to check as 2.

3. Specify the Duration with duration type as rolling and duration as 1 hour.

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

5. Specify true for Apply the filter checks on Current Transaction?.

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.

You can use this condition to specify up to six (6) filter conditions that are applied on transactions that are considered for counting.

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

General information about the Transaction: Compare Transaction Aggregrates (Sum/Avg/Min/Max) Across Two Different Durations condition is provided in the following table.

Table B-151 Transaction Aggregrates (Sum/Avg/Min/Max) Across Two Different Durations

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 must 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.

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

The following table summarizes the parameters in the Transaction: Compare Transaction Aggregrates (Sum/Avg/Min/Max) Across Two Different Durations condition.

Table B-152 Transaction: Compare Transaction Aggregrates (Sum/Avg/Min/Max) Across Two Different Durations Parameters

Parameter	Description	Possible Values	Can be Null?
Select Transaction to check	Transaction Definition fully qualified key. This is specified using list box that has list of transaction definitions		No
Select the aggregate function	Aggregrate function that must be used		No
Select Entity or Element to count	Transaction Entity/Data Element that must be aggregrated		No
Specify Duration for the 1st Aggregate	Select duration for the first aggregrate		No
Specify Duration for the 2nd Aggregate	Select duration for the second aggregrate		No
Select Comparison Condition to compare 1st aggregate with 2nd aggregate	Comparison condition		No
Multiplier for 2nd Aggregate	Multiplier value for the second aggregrate. Only nonzero and null values will be considered		Yes
Ignore Current Transaction in Aggregate?	Flag to indicate if the current transaction must be ignored		No
for the same user?	Boolean flag to indicate whether only transactions belonging to the current user to be counted or not		Yes
Specify condition for count	Condition for the count check. Select only valid operators that are relevant to numeric values		No
Specified value for count	Count value to check. Specify only valid positive integers.		No
Apply the filter checks on Current Transaction?	Flag to indicate if the filter conditions have to validated on current transaction before doing the count		No
Filter Key 1 Filter Key 2 Filter Key 3 Filter Key 4 Filter Key 5 Filter Key 6	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
Filter Condition 1 Filter Condition 2 Filter Condition 3 Filter Condition 4 Filter Condition 5 Filter Condition 6	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 must 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 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%).

B.8.9 Transaction: Compare Transaction Counts Across Two Different Durations

General information about the Transaction: Compare Transaction Counts Across Two Different Durations condition is provided in the following table.

Table B-153 Transaction: Compare Transaction Counts Across Two Different Durations

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.

Transaction: Compare Transaction Counts Across Two Different Durations Parameters

The following table summarizes the parameters in the Transaction: Compare Transaction Counts Across Two Different Durations condition.

Table B-154 Transaction: Compare Transaction Counts Across Two Different Durations Parameters

Parameter	Description	Possible Values	Can be Null?
Select Transaction to check	Transaction Definition fully qualified key. This is specified using list box that has list of transaction definitions		No
Specify Duration for the 1st count	Select duration for the first count		No
Specify Duration for the 2nd count	Select duration for the second count		No
Select Comparison Condition to compare 1st count with 2nd count	Comparison condition		No
Multiplier for 2nd count	Multiplier value for the second aggregrate. Only nonzero and null values will be considered		Yes
Ignore Current Transaction in count?	Flag to indicate if the current transaction must be ignored		No
for the same user?	Boolean flag to indicate whether only transactions belonging to the current user to be counted or not		Yes
Specify condition for count	Condition for the count check. Select only valid operators that are relevant to numeric values		No
Specify value for count	Count value to check. Specify only valid positive integers.		No
Apply the filter checks on Current Transaction?	Flag to indicate if the filter conditions have to validated on current transaction before doing the count		No
Filter Key 1 Filter Key 2 Filter Key 3 Filter Key 4 Filter Key 5 Filter Key 6	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
Filter Condition 1 Filter Condition 2 Filter Condition 3 Filter Condition 4 Filter Condition 5 Filter Condition 6	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 must be specified

Example Usage

Use this condition when you want to trigger a rule based on the comparison of transaction counts across two 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%).

B.8.10 Transaction: Compare Transaction Entity/Element Counts Across Two Different Durations

General information about the Transaction: Compare Transaction Entity/Element Counts Across Two Different Durations condition is provided in the following table.

Table B-155 Transaction: Compare Transaction Entity/Element Counts Across Two Different Durations

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.

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

The following table summarizes the parameters in the Transaction: Compare Transaction Entity/Element Counts Across Two Different Durations condition.

Table B-156 Transaction: Compare Transaction Entity/Element Counts Across Two Different Durations Parameters

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 nonzero 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 must 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
Filter Key 1 Filter Key 2 Filter Key 3 Filter Key 4 Filter Key 5 Filter Key 6	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
Filter Condition 1 Filter Condition 2 Filter Condition 3 Filter Condition 4 Filter Condition 5 Filter Condition 6	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 must 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 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%).

B.8.11 Transaction: Check Unique Transaction Entity Count with the Specified Count

General information about the Transaction: Check Unique Transaction Entity Count with the Specified Count condition is provided in the following table.

Table B-157 Transaction: Check Unique Transaction Entity Count with the Specified Count

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.

Transaction: Check Unique Transaction Entity Count with the Specified Count Parameters

The following table summarizes the parameters in the Transaction: Check Unique Transaction Entity Count with the Specified Count condition.

Table B-158 Transaction: Check Unique Transaction Entity Count with the Specified Count Parameters

Parameter	Description	Possible Values	Can be Null?
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
Select Transaction Entity to count	Select the entity/element to be counted. Only distinct values will be counted		No
Specified Condition	Specified condition	Select from drop down list.	No
Duration	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.	Select from list.	No
Transaction Status	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
For the same user?	This parameter specifies whether to evaluate the condition for the current users	Boolean. True or False	No
Ignore Current Transaction in count?	Flag to indicate if the current transaction must 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. Note: You must have the Credit card entity configured.

2. Select For the same user as true.

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

4. Set Transaction Status to Success.

5. Select Ignore Current Transaction in count? to true, so that your current transaction will not be counted.

B.9 User Conditions

The user conditions are documented in this section.

B.9.1 User: Stale Session

General information about the User: Stale Session condition is provided in the following table.

Table B-159 User: Stale Session

Condition	User: Stale Session
Description	Verify if a newer session is established after this session is created
Prerequisites	None for the 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 (concurrency check). The OAAM Session ID is checked. For example, you can configure your rules so that an action occurs when a user logs in and gets a Session ID and a fraudster logs in with the same ID and gets a new Session ID (the user is on the old session and the fraudster creates a new session).

B.9.2 User: Devices Used

General information about the User: Devices Used condition is provided in the following table.

Table B-160 User: Check User Data

Condition	User: Devices Used
Description	Number of devices tried in a given time
Prerequisites	None for the 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 Checkpoints.

User: Devices Used Parameters

The following table summarizes the parameters in the User: Devices Used condition.

Table B-161 User: Check User Data Parameters

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] The default is 0. Provide a positive integer number. (>=0)	No
Within Duration (seconds)	Users session history look-back period in seconds.	[Integer] The 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 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 must use this condition in a rule.

1. Configure Number of devices to be "N-1".

2. Configure Within Duration (seconds) to be 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.

B.9.3 User: Check If Devices Of Certain Type Are Used

General information about the User: Check If Devices Of Certain Type Are Used condition is provided in the following table.

Table B-162 User: Check If Devices Of Certain Type Are Used

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 the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions
Available since version	11.1.2.0.0
Checkpoints	All Checkpoints.

User: Check If Devices Of Certain Type Are Used Parameters

The following table summarizes the parameters in the User: Check If Devices Of Certain Type Are Used condition.

Table B-163 User: Check If Devices Of Certain Type Are Used Parameters

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] The default is More Than. Possible values are More than equal to, Less than, Less than 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] The 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] The 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] The 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 must use this condition in a rule.

1. Configure Number of devices to compare as Greater Than. Configure the Number of Devices as N-1.

2. Configure Devices of type as Mobile Device and configure Within Duration (seconds) 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.

B.9.4 User: Check Number of Registered Devices Of Given Type

General information about the User: Check Number of Registered Devices Of Given Type condition is provided in the following table.

Table B-164 User: Check Number of Registered Devices Of Given Type

Condition	User: Check Number of Registered Devices Of Given Type
Description	Number of registered devices of given type.
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	11.1.2.0.0
Checkpoints	All Runtimes.

User: Check Number of Registered Devices Of Given Type Parameters

The following table summarizes the parameters in the User: Check Number of Registered Devices Of Given Type condition.

Table B-165 User: Check Number of Registered Devices of Given Type Parameters

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] The default is 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] The default is 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] The default is 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 must use this condition in a rule.

1. Configure the Compare Number of Devices operator of this condition as Greater Than. Configure Number of (registered) devices to compare as 4.

2. Configure Devices of type as Mobile Device.

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

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

B.9.5 User: Velocity from Last Success

General information about the User: Velocity from Last Success condition is provided in the following table.

Table B-166 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 the 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 Checkpoints.

B.9.6 User: Velocity from Last Successful Login

General information about the User: Velocity from Last Successful Login condition is provided in the following table.

Table B-167 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 IP group
Prerequisites	You must have a rule configured with this condition to experience the behavior. There should be a list of IP groups already. A geolocation database is needed if you want this condition to return more accurate outcomes; otherwise all IPs are shown as Private and the condition will be a default value such as False. The condition will work without geolocation, but it would not be useful. Outcome is more accurate if there is geolocation data.
Assumptions
Available since version	10.1.4.5
Checkpoints	All Checkpoints.

User: Velocity from Last Successful Login Parameters

The following table summarizes the parameters in the User: Velocity from Last Successful Login condition.

Table B-168 User: Velocity from Last Success Parameters

Parameter	Description	Possible Values	Can be Null?
Miles per Hour is more than	Maximum number to watch for in the ratio of the distance traveled (in miles) to the time spent traveling (in hours)	Positive integer with a default of 60	No
Ignore if last login device is same	Ignore the condition if the login is from the same device.	Default is true True will return null during condition evaluation if more than one successful login of the same user from the same Device ID. If the same user has a different Device ID associated with the login, then this will not return null and an alert/action occurs. False ignores the parameter and condition evaluates only based on miles per hour.	No
Ignore IP Group	IP group to be ignored for this condition This is a list of groups that contain IP groups. The Conditions tab of the rule displays a drop-down list of IP address groups. Use the Group editor in the OAAM Administration Console to create a group or edit this group list.	IP group created through Group editor. Examples are OAAM Restricted IPs and OAAM Risky IPs.	Yes

The condition evaluates if the user's login was successful earlier and the velocity in miles per hour is more than specified value and the user has the same Device ID. If there are multiple logins of the same user from the same device then parameter "ignore if last login device is same" is used. To return null from this condition, there must be multiple logins that are successful from the same user who has the same Device ID. Location database is used to determine the location of the user for this login and previous login.

True for "Ignore if last login device is same" will return null during condition evaluation if more than one successful login of the same user from the same Device ID. If the same user has a different Device ID associated with the login, then this will not return null and an alert/action occurs. False ignores the parameter and condition evaluates only based on miles per hour.

This Ignore IP Group parameter allows you to specify a list of IPs to ignore. If the user's IP belongs to the list of IPs (the IP group), then this condition always evaluates to false and no action and/or alert is triggered. 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 from the last login. If the velocity of the user from the last login is more than the configured value in the rule, the condition evaluates to true and the condition is triggered.

Use this condition if you have a requirement that an evaluation be performed based on the physical distance between the location a user is logging in from now versus the last location he logged in from and the velocity/speed required to travel between the locations given the time if the device used is different.

1. Create a policy and add a User Velocity rule with the condition, User: Velocity from last successful login.

2. Enter a number for Miles per Hour is more than. For example, 500.

3. Select True for Ignore if last login device is same.

4. Add a KBA challenge as a result of the User Velocity rule.

For more information on group creation, see Chapter 13, "Managing Groups."

B.9.7 User: Velocity from Last Successful Login within Limits

General information about the User: Velocity from Last Successful Login within Limits condition is provided in the following table.

Table B-169 User: Velocity from Last Successful Login within Limits

Condition	User: Velocity from Last Successful Login within Limits
Description	This condition triggers when velocity from last successful login is within specified limits
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Velocity from Last Successful Login within Limits Parameters

The following table summarizes the parameters in the User: Velocity from Last Successful Login within Limits condition.

Table B-170 User: Velocity from Last Successful Login within Limits Parameters

Parameter	Description	Possible Values	Can be Null?
Velocity above or equal	Lower bound of the distance traveled.	Default is 100	No
And below or equal	Upper bound of the distance traveled.	Default is 300	No
Then, trigger	If then trigger is True, the rule triggers if the condition is met. If then trigger is False, the rule condition will trigger only if the condition is not met.	Default is True	No
Ignore if last login device is same	If last login device is the same, do not perform any action	Default is True	No

It is possible for a user to log in to their application, then board a Jet and fly to another city and once again log in to the same application.

1. The Rule first picks up the last successful login in last N seconds. (If there are multiples then the last one (with the highest timestamp) will be picked.

2. The Rule looks at cityLastLogin and currentCurrentLogin and finds the distance between them which is equal to the distance.

3. Then 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 UI) then the rule will trigger.

B.9.8 User: Distance from Last Successful Login

General information about the User: Distance from Last Successful Login condition is provided in the following table.

Table B-171 User: Distance from Last Successful Login

Condition	User: Distance from Last Successful Login
Description	Distance from last successful login within specified time
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Distance from Last Successful Login Parameters

The following table summarizes the parameters in the User: Distance from Last Successful Login condition.

Table B-172 User: Distance from Last Successful Login Parameters

Parameter	Description	Possible Values	Can be Null?
Miles more than	Maximum number of miles to watch for. If the number of miles exceeds this number, then the condition will evaluate to true.	Default is 300	No
Within Duration (seconds)	Time period in seconds to look back into users session history. Seconds elapsed	[Integer] The 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

B.9.9 User: Distance from Last Successful Login within Limits

General information about the User: Distance from Last Successful Login within Limits condition is provided in the following table.

Table B-173 User: Distance from Last Successful Login within Limits

Condition	User: Distance from Last Successful Login within Limits
Description	Checks if distance from last successful login within specified time is within limits
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Distance from Last Successful Login within Limits Parameters

The following table summarizes the parameters in the User: Distance from Last Successful Login within Limits condition.

Table B-174 Distance from Last Successful Login within Limits Parameters

Parameter	Description	Possible Values	Can be Null?
in past (seconds)	Seconds elapsed	Default is 3600	No
Distance above or equal	Lower limit of distance value	Default is 100	No
And below or equal	Upper limit of distance value	Default is 300	No
Then, trigger	If then trigger is true, the rule triggers if the condition is met. If then trigger is False, the rule condition will trigger only if the condition is not met.	Default is True	No

B.9.10 User: Authentication Image Assigned

General information about the User: Authentication Image Assigned condition is provided in the following table.

Table B-175 User: Authentication Image Assigned

Condition	User: Authentication Image Assigned
Description	Checks if authentication image is assigned to the user
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Authentication Image Assigned Parameters

The following table summarizes the parameters in the User: Authentication Image Assigned condition.

Table B-176 User: Authentication Image Assigned

Parameter	Description	Possible Values	Can be Null?
Is assigned	Checks if the condition should return true or false if the authentication image is assigned to the user.	True/false	No

If you want the user to register an image, use this condition to check if the user has already registered an image. If an image has not been registered, an action may be taken such as forcing the user to register an image. If an image is registered, an action might be taken such that the authentication image is displayed in an assisted page.

As standard, the default OAAM rules are in place so that if the user registered an image, the virtual authenticator with authentication image is displayed in an OAAM Server page.

B.9.11 User: Authentication Mode

General information about the User: Authentication Mode condition is provided in the following table.

Table B-177 User: Authentication Mode

Condition	User: Authentication Mode
Description	Check user authentication mode
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Authentication Mode Parameters

The following table summarizes the parameters in the User: Authentication Mode condition.

Table B-178 User: Authentication Mode Parameters

Parameter	Description	Possible Values	Can be Null?
Authentication mode is	Authentication mode of the user. For example, the condition checks if the authentication mode of the user is "Full KeyPad"	The authentication values are from the auth.client.type.enum property. For example, possible values can be: Full KeyPad TextPad	No

The condition checks the authentication mode of the user, for example, Textpad or Full Keypad. If you have an option to upgrade from Textpad to Keypad, this is the condition used to check the state.

The list of authentication modes is defined in Java properties as user-defined-enum "auth.client.type.enum".

B.9.12 User: Status Count Timed

General information about the User: Status Count Timed condition is provided in the following table.

Table B-179 User: Status Count Timed

Condition	User: Status Count Timed
Description	User attempted multiple logins in specified time
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Status Count Timed Parameters

The following table summarizes the parameters in the User: Status Count Timed condition.

Table B-180 User: Status Count Timed Parameter

Parameter	Description	Possible Values	Can be Null?
Authentication status is	Authentication status.	Authentication status is configured through auth.status.enum. For example: Blocked Locked Database Error Password Expired Invalid User Pending Pending activation Session expired Session reused Success System Error User is disabled Wrong answer Wrong password Wrong pin	No
Within Minutes	This parameter defines the period in which the login attempts that the user made are counted.	Default is 30	No
for more than	Maximum number of logins to watch for. If the login count exceeds this number within minutes with a certain authentication status, then the condition will evaluate to true.	Default is 3	No

B.9.13 User: Challenge Timed

General information about the User: Challenge Timed condition is provided in the following table.

Table B-181 User: Challenge Timed

Condition	User: Challenge Timed
Description	Checks if user answered challenge question successfully in last n minutes
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Challenge Timed Parameters

The following table summarizes the parameters in the User: Challenge Timed condition.

Table B-182 User: Challenge Timed

Parameter	Description	Possible Values	Can be Null?
Is	This is a boolean parameter that defines a default return value if user answered challenge question successfully in last n minutes.	Default is True	No
Within Minutes	This parameter defines the period in which the challenge questions that were answered correctly are counted.	Default is 30	No

B.9.14 User: Challenge Channel Failure

General information about the User: Challenge Channel Failure condition is provided in the following table.

Table B-183 User: Challenge Channel Failure

Condition	User: Challenge Channel Failure
Description	If a user has a failure counter value over a specified value from specific channel. The total number of challenge failures a user is allowed before an action occurs that is configured in this rule condition.
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Challenge Channel Failure Parameters

The following table summarizes the parameters in the User: Challenge Channel Failure condition.

Table B-184 User: Challenge Channel Failure

Parameter	Description	Possible Values	Can be Null?
Challenge Channel	The challenge rule action for challenging the user; whether or not customer care asks the challenge question or it is a challenge by online method Value is from tracker.challenge.channel.enum.	Possible values are Online (Online challenge channel) and Cases (Customer care challenge channel)	No
Current Question Count only?	Count failures for current KBA challenge questions only or for all KBA challenge questions.	Default is False For example, does the user make 3 or 4 attempts for the current question or does the user can make 3 or 4 attempts counting the current question along with the previous questions?	No
Failures greater than or equal to	Number of failures	Default is 3	No

This condition is used to check if the user has been asked the question a certain number of times for a challenge channel, and if the failure counter value is over a specified value, the rule triggers to take an action, such as proceeding to the next question.

An example scenario could be the following:

For the Online Counter: If the user is answering challenge questions online, and if the user is given a maximum of three attempts to provide a correct answer, one attempt per question, each failure to answer a question increments the Online Counter. An action could be for the user to be locked out of the session after three failures.

For the Phone Counter: If the CSR is asking the user challenge questions by phone, and if the user is given a maximum of three attempts per question, a total of nine attempts is allowed. The user is advanced to the next question after three attempts in answering the current question. Each failure to answer the question increments the Phone Counter. An action could be for the user to be locked out of the session after three failures (nine attempts).

B.9.15 User: Challenge Questions Failure

General information about the User: Challenge Questions Failure condition is provided in the following table.

Table B-185 User: Challenge Questions Failure

Condition	User: Challenge Questions Failure
Description	Checks how many questions have failures. This condition checks for the total number of failures without the options to count the failure for the current question only or specify the challenge channel used.
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Challenge Questions Failure Parameters

The following table summarizes the parameters in the User: Challenge Questions Failure condition.

Table B-186 User: Challenge Questions Failure

Parameter	Description	Possible Values	Can be Null?
Failures more than or equal to	Maximum number of failures to watch for. If the failure count exceeds this number, then the condition will evaluate to true.	Default is 1	No

Use this condition if you are using KBA questions, and you want to check the number of failures the user has, triggering the rule if the user has failed to answer multiple challenge questions.

If the user answers the KBA question incorrectly, he is allowed other attempts until he either answers correctly or the maximum number of failures is reached and the rule triggers. An action that results when the rule triggers could be that he is locked out of his account. In the OAAM-server based policies, the user is allowed three attempts total to provide the correct answer. If there are more than three failed attempts, the rule triggers.

B.9.16 User: Challenge Failure - Minimum Failures

General information about the User: Challenge Failure - Minimum Failures condition is provided in the following table.

Table B-187 User: Challenge Failure - Minimum Failures

Condition	User: Challenge Failure - Minimum Failures
Description	If a user has a failure counter value over a specified value.
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Challenge Failure - Minimum Failures Parameters

The following table summarizes the parameters in the User: Challenge Failure - Minimum Failures condition.

Table B-188 User: Challenge Failure - Minimum Failures Parameters

Parameter	Description	Possible Values	Can be Null?
Failures greater than	Maximum number of failures to watch for. If the failure count exceeds this number, then the condition will evaluate to true.	Default is 0	No

B.9.17 User: Challenge Maximum Failures

General information about the User: Challenge Maximum Failures condition is provided in the following table.

Table B-189 User: Challenge Maximum Failures

Condition	User: Challenge Maximum Failures
Description	Checks if user failed to answer challenge question for specified number of times. You can choose to count the failure for the current question only.
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Challenge Maximum Failures Parameters

The following table summarizes the parameters in the User: Challenge Maximum Failures condition.

Table B-190 User: Challenge Maximum Failures

Parameter	Description	Possible Values	Can be Null?
Number of Failures More than or equal to	Maximum number of failures to watch for. If the failure count exceeds this number, then the condition will evaluate to true.	Default is 3	No
Current Question Count only?	Increment question counter per question?	Default is False	Yes
If above or equal, return	The value to return if above or equal to the number of failed attempts allowed.	Default is True	Yes

Use this condition when you want to trigger a rule based on the number of times per question or number of times in a row the user can fail to answer a question correctly.

B.9.18 User: Challenge Failure Is Last Challenge Before

General information about the User: Challenge Failure Is Last Challenge Before condition is provided in the following table.

Table B-191 User: Challenge Failure Is Last Challenge Before

Condition	User: Challenge Failure Is Last Challenge Before
Description	If it is a last challenge before number of hours, since number of days have passed.
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Challenge Failure Is Last Challenge Before Parameters

The following table summarizes the parameters in the User: Challenge Failure Is Last Challenge Before condition.

Table B-192 User: Challenge Failure Is Last Challenge Before Parameters

Parameter	Description	Possible Values	Can be Null?
Client Type	Client used	Possible values are Alpha Keypad Applet Tracker Challenge Response Default Email Eye Scan Flash Tracker Full KeyPad Hand Fingerprint Image Tracker Login Page Native Mobile Client Normal OCS Question OTP Partial Password PinPad Question and Answer SMS Slider TextPad Token Transaction Signing Unknown Wheel	No
Minimum days since last Challenge	Minimum amount of time elapsed since the last challenge	Default is 1	No
Maximum days to look back	Maximum amount of time elapsed to consider	Default is 30	No

B.9.19 User: Check OTP Failures

General information about the User: Check OTP Failures condition is provided in the following table.

Table B-193 User: Check OTP Failures

Condition	User: Check OTP Failures
Description	Checks if user's OTP failure counter value is over a specified value.
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	11.1.1.5
Checkpoints	All checkpoints

User: Check OTP Failures Parameters

The following table summarizes the parameters in the User: Check OTP Failures condition.

Table B-194 User: Check OTP Failures Parameters

Parameter	Description	Possible Values	Can be Null?
Failures more than or equal to	When the number of failures is more than this number, the condition triggers.	Default is 0	No
If above or equal, return	The value to return if above or equal to the number of failed attempts in which this condition will trigger. For example, if the number is 5, and the OTP failures are more than 5, the condition will trigger. 0 returns True or False if above or equal.	Default is True	No
OTP Challenge Type	Challenge Type is the configuration of a type of challenge (ChallengeEmail, ChallengeSMS, ChallengeQuestion)	Default is ChallengeSMS Possible challenge type values are: ChallengeEmail: OTP challenge via e-mail ChallengeSMS: OTP challenge via Short Message Service (SMS) ChallengeIM: OTP challenge via instant messaging Values are from the challenge.type.enum property. Through this enum, you can add challenge types.	No

This condition is used in a rule that OTP-challenges users for specific scenarios. If the user answers OTP incorrectly, he is allowed other attempts until he either answers correctly or is locked out of his account after a certain number of failures. When a user fails the OTP challenge, a counter is updated to indicate that user has had a failure. In the OAAM-server based policies, the user is allowed three attempts to provide the correct answer. If there are more than three failed OTP attempts, the rule triggers. The failure counter is set by default in the OAAM Challenge Policy, but you can customize it.

B.9.20 User: Multiple Failures

General information about the User: Multiple Failures condition is provided in the following table.

Table B-195 User: Multiple Failures

Condition	User: Multiple Failures
Description	User failed multiple times
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Multiple Failures Parameters

The following table summarizes the parameters in the User: Multiple Failures condition.

Table B-196 User: Multiple Failures Parameters

Parameter	Description	Possible Values	Can be Null?
Authentication status is not	User account status	Possible values are: Blocked Database Error Invalid User Locked Password Expired Pending Pending Activation Session Expired Session Reused Success System Error User Disabled Wrong Answer Wrong PIN Wrong Password	No
for more than	Maximum number of failures to watch for. If the failure count exceeds this number, then the condition will evaluate to true.	Default is 3	No

This checks if the user has failed multiple times with a user account status that is not the one specified.

B.9.21 User: In Group

General information about the User: In Group condition is provided in the following table.

Table B-197 User: In Group

Condition	User: In Group
Description	Checks if user is in the group specified
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: In Group Parameters

The following table summarizes the parameters in the User: In Group condition.

Table B-198 User: In Group Parameters

Parameter	Description	Possible Values	Can be Null?
Is in group	The parameter controls the outcome of the condition. You can negate the outcome of the condition with this parameter. If the user is in the user group and the value of this parameter is True, the condition evaluates to True. If the user is not in the user group and the value of this parameter is False, the condition evaluates to True. In all other cases, the condition evaluates to False.	Default is True	No
User Group	This is a list of groups that contain users. The Conditions tab of the rule displays a drop-down list of user groups. Use the Group editor in the OAAM Administration Console to create a group or edit this group list.	Default or OAAM Restricted Users	No

Use this condition to determine if an action needs to be performed on a user of the current activity. For example, a group of users could be considered high risk, so you can configure a policy to always challenge the users in the High Risk user group.

For more information on group creation, see Chapter 13, "Managing Groups."

B.9.22 User: Login in Group

General information about the User: Login in Group condition is provided in the following table.

Table B-199 User: Login in Group

Condition	User: Login in Group
Description	If the user login is in the given group
Prerequisites	You must have a rule configured with this condition to experience the behavior. Use the Group editor in the OAAM Administration Console to create a group or edit this group list.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Login in Group Parameters

The following table summarizes the parameters in the User: Login in Group condition.

Table B-200 User: Login in Group Parameters

Parameter	Description	Possible Values	Can be Null?
Is in group	The parameter controls the outcome of the condition. You can negate the outcome of the condition with this parameter. If the user login is in the group and the value of this parameter is True, the condition evaluates to True. If the user login is not in the group and the value of this parameter is False, the condition evaluates to True. In all other cases, the condition evaluates to False.	Default is False	No
User Group	This is a list of groups that contain users. The Conditions tab of the rule displays a drop-down list of user groups. Use the Group editor in the OAAM Administration Console to create a group or edit this group list.	User group from a list of user groups	No

For more information on group creation, see Chapter 13, "Managing Groups."

B.9.23 User: User Group in Group

General information about the User: User Group in Group condition is provided in the following table.

Table B-201 User: User Group in Group

Condition	User: User Group in Group
Description	If the user group is in the given group
Prerequisites	You must have a rule configured with this condition to experience the behavior. Use the Group editor in the OAAM Administration Console to create a group or edit this group list.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: User Group in Group Parameters

The following table summarizes the parameters in the User: User Group in Group condition.

Table B-202 User: User Group in Group Parameters

Parameter	Description	Possible Values	Can be Null?
Is in group	This is a boolean parameter that defines a default return value if the user group is in the group.	Default is True	No
Group List	This is a list of groups that contain users. The Conditions tab of the rule displays a drop-down list of user groups. Use the Group editor in the OAAM Administration Console to create a group or edit this group list.	User group from a list of user groups	No

This condition checks if the user belongs or does not belong to a certain user group.

For more information on group creation, see Chapter 13, "Managing Groups."

B.9.24 User: Action Count

General information about the User: Action Count condition is provided in the following table.

Table B-203 User: Action Count

Condition	User: Action Count
Description	Checks action counter for the given action. This condition has dependency on action configuration
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Action Count Parameters

The following table summarizes the parameters in the User: Action Count condition.

Table B-204 User: Action Count Parameters

Parameter	Description	Possible Values	Can be Null?
Action	Contains action	Default is Password Values are specified in the rule.action.enum property.	No
Count Above or Equal to	Maximum number of actions to watch for. If the action count for this action exceeds this number, then the condition will evaluate to true.	Default is 3	No

This condition checks if the maximum count of an action has been met.

B.9.25 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

General information about the User: Action Count Timed condition is provided in the following table.

Table B-205 User: Action Count Timed

Condition	User: Action Count Timed
Description	Checks if the given action count is more than specified count. If checkpoint is not specified, action is checked in all checkpoints
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	Action is check against a specific checkpoint or against all checkpoints.

User: Action Count Timed Parameters

The following table summarizes the parameters in the User: Action Count Timed condition.

Table B-206 User: Action Count Timed Parameters

Parameter	Description	Possible Values	Can be Null?
Checkpoint (Optional)	A specific checkpoint is provided or if it is not, the action is checked against all checkpoints.	Possible values configured through the profile.type.enum property.	Yes
Action	Action to be checked. This condition is cumulative for all actions counted that occurred across sessions.	Possible values configured through the rule.action.enum property. An example of an action is Challenge.	No
in seconds	Seconds elapsed in which to check action count.	Default is 300	No
Count Action only once per session?	Specify if you want the action only counted once per session. An action can occur a number of times within a session. For example, a user can be challenged more than once in a given session. If you specify Count Action only once per session? as false, if the end user is challenged 3 times in the one session, OAAM counts all of the Challenge actions that occurred in the last 300 seconds. If the end user is challenged 10 times in 5 sessions, OAAM counts the Challenge action as 10. If you specify Count Action only once per session? as True, if the end user is challenged 3 times in one session, OAAM counts the Challenge actions that occurred in the last 300 seconds as 1. If the end user is challenged 3 times each session in 5 sessions, OAAM counts the Challenge actions as 5.	Default is True	No
More than	Maximum action count across sessions in specified n seconds.	Default is 3	No

Use this condition if you want to check if the action count across sessions in the last n seconds is more than the number specified. The condition has a parameter to specify if you want to count the action as one time per session or a number of separate times in a session. For example, you might want to count the actual number of Challenges irrespective to the number of sessions if you are running a transaction scenario and want to send an OTP challenge a number of times in the last n seconds. You might want to challenge the user only 2 or 3 times and not challenge him again or you might want to keep challenging him even if the user has been challenged a number of times in a session. For example, if in the last 5 minutes, irregardless of the number of sessions, you do not want the end user to be challenged a third time. On the other hand, you might only want the user to be challenged once per session or transfer.

B.9.26 User: Check Last Session Action

General information about the User: Check Last Session Action condition is provided in the following table.

Table B-207 User: Check Last Session Action

Condition	User: Check Last Session Action
Description	Checks if the given action is in last session. If checkpoint is not specified, action is checked in all checkpoints of that session
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Check Last Session Action Parameters

The following table summarizes the parameters in the User: Check Last Session Action condition.

Table B-208 User: Check Last Session Action

Parameter	Description	Possible Values	Can be Null?
Checkpoint (Optional)	Checkpoints to choose from	Possible values configured through the profile.type.enum property.	No
Action	Contains action	Default is Password	No
in seconds	Seconds elapsed	Default is 300	No

B.9.27 User: Account Status

General information about the User: Account Status condition is provided in the following table.

Table B-209 User: Account Status

Condition	User: Account Status
Description	Checks the account status of the user.
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Account Status Parameters

The following table summarizes the parameters in the User: Account Status condition.

Table B-210 User: Account Status Parameter

Parameter	Description	Possible Values	Can be Null?
User Account Status	Account status of the user	Account status is configured through the vcrypt.user.account.status.enum property. Values are. Active The user is active and available in the system. He has completed registration and can perform all operations. Deleted The user is not available in the system. Disabled The user is available in the system, but not active. He maybe disabled because of fraud or other reasons and cannot perform any operations. Invalid The user name is not valid. Pending Activation The user started registration, but has not completed it. He has entered his user name and password and his information has been stored in the database, but he will not be activated until he has completed registration. The user is available in the system, but he is not yet active and cannot perform any operations.	No
Is	Boolean parameter to decide if the default return value should be true or false if the account status is the one specified.	True or False	No

Use this condition if you want to check the account status of the user. For example, if the user status is Disabled or Invalid, you may have configured an action to block the user because you do not want the user to proceed with the steps to access the resource.

B.9.28 User: Client And Status

General information about the User: Client And Status condition is provided in the following table.

Table B-211 User: Client And Status

Condition	User: Client And Status
Description	Account status of the user
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Client And Status Parameters

The following table summarizes the parameters in the User: Client And Status condition.

Table B-212 User: Client And Status Parameters

Parameter	Description	Possible Values	Can be Null?
Used client	Client type	Possible values are Alpha Keypad Applet Tracker Challenge Response Default Email Eye Scan Flash Tracker Full KeyPad Hand Fingerprint Image Tracker Login Page Native Mobile Client Normal OCS Question OTP Partial Password PinPad Question and Answer SMS Slider TextPad Token Transaction Signing Unknown Wheel	No
Within duration (minutes)	The period to count the number of times the user logged in from the client type successfully.	Default is 1440	No
More than	Number of times the user logged in from the client type successfully.	Default is 3	No

Use this condition to check if the user logged in successfully from the client type within the specified minutes. This condition checks for the status of Success.

B.9.29 User: Question Status

General information about the User: Question Status condition is provided in the following table.

Table B-213 User: Question Status

Condition	User: Question Status
Description	Question status of the user
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Question Status Parameters

The following table summarizes the parameters in the User: Question Status condition.

Table B-214 User: Question Status Parameters

Parameter	Description	Possible Values	Can be Null?
User Question Status	User question registration status Status value is from vcrypt.user.question.status.enum.	Set or Not Set	No
is	Checks if the condition should return Yes or No if the question status is the one specified.	Default is Yes	No

Use this condition to check if the challenge questions are set for the user. If the challenge questions are not set for the user (unregistered users), an action may be taken such as forcing the user to register questions. If the questions are set, an action might be taken such that the challenge questions are used for risky situations.

B.9.30 User: Image Status

General information about the User: Image Status condition is provided in the following table.

Table B-215 User: Image Status

Condition	User: Image Status
Description	Image status of the user
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Image Status Parameters

The following table summarizes the parameters in the User: Image Status condition.

Table B-216 User: Image Status

Parameter	Description	Possible Values	Can be Null?
User Image Status	User account status	Set or Not set	No
Is	Checks if account status is set	Default is True	No

B.9.31 User: Phrase Status

General information about the User: Phrase Status condition is provided in the following table.

Table B-217 User: Phrase Status

Condition	User: Phrase Status
Description	Phrase status of the user
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Phrase Status Parameters

The following table summarizes the parameters in the User: Phrase Status condition.

Table B-218 User: Phrase Status parameters

Parameter	Description	Possible Values	Can be Null?
User Phrase Status	User account status	Set or Not set	No
Is	Checks if the condition should return true or false if the user has his phrase registered or not.	Default is True	No

Use this condition to check if the user has or has not registered his security phrase.

B.9.32 User: Preferences Configured

General information about the User: Preferences Configured condition is provided in the following table.

Table B-219 User: Preferences Configured Parameters

Condition	User: Preferences Configured
Description	Checks if the user preferences are set
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Preferences Configured Parameters

The following table summarizes the parameters in the User: Preferences Configured condition.

Table B-220 User: Preferences Configured

Parameter	Description	Possible Values	Can be Null?
Is configured	Boolean parameter to decide if the default return value should be true or false if the user preferences are set.	Default is True	No

Use this condition to check if the user has or has not set user preferences.

B.9.33 User: Check Information

General information about the User: Check Information condition is provided in the following table.

Table B-221 User: Check Information

Condition	User: Check Information
Description	Checks to see if user information is set. Information data to check is sent as a key-value pair.
Prerequisites	To make use of this condition, a rule must be configured with this condition.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Check Information Parameters

The following table summarizes the parameters in the User: Check Information condition.

Table B-222 User: Check Information Parameters

Parameter	Description	Possible Values	Can be Null?
Key to comma separated values to check	Key to context map with comma separated values to check	Default is key You must enter this value. The condition checks for a non-null parameter key.	No
If information is set, return	Value to return true or false if the information is set.	Default is True	No

Use this condition to check if the value specified in the key is set or if the value specified by the key is empty ('') or null for the user. If the value is empty, OAAM sets it as null. A value that is made of spaces (" ") is set. A value made up of equal signs (=) is not set. You can specify true or false to check if the value of the key is set or if the value of the key is empty or null. This condition is mainly used to check the input fields for OTP. For a comma-separated list of keys, if all the keys have their values set, then it will return true if you specified to return true if the value is set, or false if you specify to return false if the value is set. In a comma-separated list, if any of the keys do not have their value set, the negative of the return value for if the information is set is returned.

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 e-mail 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. If the email field is set, the condition evaluates to true.

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 standard base policies that are shipped with 11g. The user will register for OTP on the first or second login.

3. Run authentications with the registered users.

   You can see the rule triggers 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.

5. Run authentications for the 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)

B.9.34 User: Check User Data

General Information about the User: Check User Data Condition

General information about the User: Check User Data condition is provided in the following table.

Table B-223 User: Check User Data

Condition	User: Check User Data
Description	Verify if specified key has any related data for the user
Prerequisites	None for the 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 Checkpoints.

User: Check User Data Parameters

The following table summarizes the User: Check User Data condition parameters.

Table B-224 User: Check User Data

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] You must know the key to check. Note: You can only check one key.	No

Use the User: Check User Data condition to validate if the key is set or not. The condition always returns true if there is a value.

Note:

Use the User: Check Information condition instead of this condition. The User: Check Information condition allows you to specify if you want true or false returned when checking whether the key is set or not.

B.9.35 User: User Agent Percentage Match

General Information about the User: User Agent Percentage Match Condition

General information about the User: User Agent Percentage Match condition is provided in the following table.

Table B-225 User: User Agent Percentage Match Condition General Information

Condition	User: User Agent Percentage Match
Description	Checks if user agent percentage match is above specified percentage. Compares with browser user agent string (UAS) of previous login from same device
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: User Agent Percentage Match Parameters

The following table summarizes the parameters in the User: User Agent Percentage Match condition.

Table B-226 User: User Agent Percentage Match Parameters

Parameter	Description	Possible Values	Can be Null?
Is	Boolean parameter to decide if the default return value should be true or false if the agent percentage match is above the specified percentage.	Default is False	No
percentage match above	Agent percentage match is above specified percentage	Default is 60	No
From Same Device?	Boolean parameter to decide if the default return value should be true or false if the device is the same device.	Default is True	No

This condition assumes that you know the keys that you are expecting in a user agent string. The condition checks how many of those values match (how similar is the user agent string to the previous user agent string). This condition is used for the Device ID rules.

B.9.36 User: Is User Agent Match

General information about the User: Is User Agent Match condition is provided in the following table.

Table B-227 User: Is User Agent Match

Condition	User: Is User Agent Match
Description	Checks if user agent matches with that of previous login from the same device
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Is User Agent Match Parameters

The following table summarizes the parameters in the User: Is User Agent Match condition.

Table B-228 User: Is User Agent Match

Parameter	Description	Possible Values	Can be Null?
Is	This is a boolean parameter that defines a default return value if the user agent matches that of the previous login from the same device.	Default is False	No
From Same Device?	Device is the same device	Default is True	No

Use this condition to check if the user agent string matches that of the previous login's user agent string from the same device.

B.9.37 User: Check Fraudulent User Request

General information about the User: Check Fraudulent User Request condition is provided in the following table.

Table B-229 User: Check Fraudulent User Request

Condition	User: Check Fraudulent User Request
Description	Check if the current User Request is fraudulent
Prerequisites	Prerequisites are as follows: A rule must be configured with this condition to experience the behavior. ODM Database User has been created. Feedback is essential to keep up with newly classified data. Feedback is also required to keep up with trends in recent data. Rebuild models with recent data is the feedback mechanism so that models are up-to-date. The date range for the data to be considered can be configured using the property oracle.oaam.predictive_analysis.request.period.
Assumptions	None
Available since version	11g
Checkpoints	Post Authentication checkpoint

User: Check Fraudulent User Request Parameters

The following table summarizes the parameters in the User: Check Fraudulent User Request condition.

Table B-230 User: Check Fraudulent User Request Parameter

Parameter	Description	Possible Values	Can be Null?
Select the Classification Model to use for evaluation	Choose the classification model you want to use to evaluate the current request.	OAAM Anomalous Request Model or OAAM Fraud Request Model The classification type is from an enum.	No
Select the required classification type	This should be the same as the value of the target column of your ODM model.	Fraud or Not Fraud	No
Enter the minimum value of probability required to predict the given classification type	Threshold probability value for fraudulent requests	Default is 0.80 Probability value should be between 0 (lowest probability) and 1 (highest probability). You can also specify decimal values like 0.85 Based on the data and requirements, range of probability can be adjusted.	No
Enter the maximum value of probability required to predict the given classification type	Minimum probability value for fraudulent requests	Default is 1.00 Probability value should be between 0 (lowest probability) and 1 (highest probability). You can also specify decimal values like 0.85 Based on the data and requirements, range of probability can be adjusted.	No
Default value to return in case of errors	The value to return in case of errors	Default is False	No

This condition is based on ODM data. The underlying triggers in ODM returns a value, that value is compared to the OAAM value, and an action can be triggered because of that. Predictive Analysis rules check if the outcome from ODM is in the specified range of probability.

Use this condition to check if the request looks similar to any of the known fraud requests.

B.9.38 User: Check Anomalous User Request

General information about the User: Check Anomalous User Request condition is provided in the following table.

Table B-231 User: Check Anomalous User Request

Condition	User: Check Anomalous User Request
Description	Check if the current User Request is Anomalous
Prerequisites	Prerequisites are as follows: A rule must be configured with this condition to experience the behavior. ODM Database User has been created. Feedback is essential to keep up with newly classified data. Feedback is also required to keep up with trends in recent data. Rebuild models with recent data is the feedback mechanism so that models are up-to-date. The date range for the data to be considered can be configured using the property oracle.oaam.predictive_analysis.request.period.
Assumptions	None
Available since version	11g
Checkpoints	Post Authentication checkpoint

User: Check Anomalous User Request Parameters

The following table summarizes the parameters in the User: Check Anomalous User Request condition.

Table B-232 User: Check Anomalous User Request

Parameter	Description	Possible Values	Can be Null?
Select Anomaly Model to use for evaluation	Choose the anomaly model you want to use to evaluate the current request.	OAAM Anomalous Request Model or OAAM Fraud Request Model	No
Enter the minimum value of probability required to classify the user request as anomalous	Probability value should be between 0 and 1. You can specify decimal values like 0.85	Default is 0.80 Based on the data and requirements, range of probability can be adjusted.	No
Enter the maximum value of probability required to classify the user request as anomalous	Probability value should be between 0 and 1. You can specify decimal values like 0.85	Default is 1.00 Based on the data and requirements, range of probability can be adjusted.	No
Default value to return in case of errors	Specify the value to be returned in case of errors.	Default is False	Yes

OAAM submits the request to ODM to see how problematic the request looks based on the configured percentage, a number between 0 and 1. It depends on the model that exists in ODM. Predictive Analysis rules check if the outcome from ODM is in the specified range of probability.

Use this condition to check if the request is anomalous compared to the existing set of requests.

B.9.39 User: User is Member of Pattern N Times

General information about the User: User is Member of Pattern N Times condition is provided in the following table.

Table B-233 User: User is Member of Pattern N Times

Condition	User: User is Member of Pattern N Times
Description	Checks if this user has been member of this pattern condition
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: User is Member of Pattern N Times Parameters

The following table summarizes the parameters in the User: User is Member of Pattern N Times condition.

Table B-234 User: User is Member of Pattern N Times

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.	Default is 0	No
Pattern Name for membership	Pattern for which membership count will be checked.	Out-of-the-box patterns are listed as follows, although you can use your own patterns: User: Device profiling pattern User: ISP profiling pattern User: Country profiling pattern User: Connection type profiling pattern User: ASN profiling pattern User: State profiling pattern User: Locale profiling pattern User: Day of Week profiling pattern User: Routing type profiling pattern User: Time range profiling pattern	No
Is Membership Count More than patternHitCountForUser	Boolean value that is used to return true or false from the condition. Use this parameter to negate the outcome of the condition. If this parameter is True and the pattern hit count is more than the specified amount for the user is True, then the condition evaluates to True. If this parameter is False and the pattern hit count is more than the specified amount for the user is False, then the condition evaluates to True. The condition evaluates to False in all other cases.	Default is True	No
Time period type for pattern membership	The time period type (hours, days, months, and years)	The time period type is defined in the work.type.enum property. The time period types are hour, day, month, and year. Time period type to select from the drop-down list are: Hours Days Months Years	No
Time period for pattern membership	The time period over which the pattern membership is evaluated.	Use 1 through 23 for hours. 1 through 30 for days. 1 through 12 for months and 1 through 8 for years. The OAAM Server will use the maximum values if you enter values more than the above specified.

B.9.40 User: User Country for First Time

General information about the User: User Country for First Time condition is provided in the following table.

Table B-235 User: User Country for First Time

Condition	User: User Country for First Time
Description	This checks to see if the user has logged in from this country successfully before
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: User Country for First Time Parameters

The following table summarizes the parameters in the User: User Country for First Time condition.

Table B-236 User: User Country for First Time parameters

Parameter	Description	Possible Values	Can be Null?
First Time	Checks if the condition should return true or false if the country has been used successfully before.	Default is True	No

Use this condition to check whether the user has logged in successfully from this country before. The status must be "Success".

B.9.41 User: Country First Time for User

General information about the User: Country First Time for User condition is provided in the following table.

Table B-237 User: Country First Time for User

Condition	User: Country First Time for User
Description	Is the user using this country for the first time?
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Country First Time for User Parameters

The following table summarizes the parameters in the User: Country First Time for User condition.

Table B-238 User: Country First Time for User

Parameter	Description	Possible Values	Can be Null?
Is First Time?	Checks if the condition should return true or false if the user is using the country for the first time.	Default is True	No

This condition is used to determine if the user is logging in from this country for the first time irrespective of the status. This condition is different from the User: User Country for First Time condition because it is irrespective of the status, whereas the User: User Country for First Time condition must have the status of "Success."

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

B.9.42 User: Country First Time from Group

General information about the User: Country First Time from Group condition is provided in the following table.

Table B-239 User: Country First Time from Group

Condition	User: Country First Time from Group
Description	If this country is used for the first time by this user from the given country group
Prerequisites	You must have a rule configured with this condition to experience the behavior. Use the Group editor in the OAAM Administration Console to create a group or edit this group list.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Country First Time from Group Parameters

The following table summarizes the parameters in the User: Country First Time from Group condition.

Table B-240 User: Country First Time from Group Parameters

Parameter	Description	Possible Values	Can be Null?
From group	Is in group	Default is True	No
Country in country group	This is a list of groups that contain countries. The Conditions tab of the rule displays a drop-down list of country groups. Use the Group editor in the OAAM Administration Console to create a group or edit this group list.	OAAM Monitoring Countries or OAAM Restricted Countries	No

This condition could potentially be used to determine if the user is logging in from a country in a group of countries and to challenge him when it is the case.

For more information on group creation, see Chapter 13, "Managing Groups."

B.9.43 User: User State for First Time

General information about the User: User State for First Time condition is provided in the following table.

Table B-241 User: User State for First Time

Condition	User: User State for First Time
Description	This checks if the user has used this state successfully previously
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: User State for First Time Parameters

The following table summarizes the parameters in the User: User State for First Time condition.

Table B-242 User: User State for First Time Parameters

Parameter	Description	Possible Values	Can be Null?
First Time	Checks if the condition should return true or false if the city has been used before.	Default is True	No

Use this condition to check whether the user has logged in successfully from this state before. The status must be "Success".

B.9.44 User: State First Time for User

General information about the User: State First Time for User condition is provided in the following table.

Table B-243 User: State First Time for User

Condition	User: State First Time for User
Description	Is the user using this state for the first time?
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: State First Time for User Parameters

The following table summarizes the parameters in the User: State First Time for User condition.

Table B-244 User: State First Time for User Parameters

Parameter	Description	Possible Values	Can be Null?
Is	This is a boolean parameter that defines a default return value if the user is using the state for the first time.	Default is True	No

This condition is used to determine if the user is logging in using this state for the first time irrespective of the status.

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

B.9.45 User: User City for First Time

General information about the User: User City for First Time condition is provided in the following table.

Table B-245 User: User City for First Time

Condition	User: User City for First Time
Description	This checks to see if the user has used this city successfully previously
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: User City for First Time Parameters

The following table summarizes the parameters in the User: User City for First Time condition.

Table B-246 User: User City for First Time Parameters

Parameter	Description	Possible Values	Can be Null?
First Time	Checks if the condition should return true or false if the city has been used successfully before.	Default is True	No

Use this condition to check whether the user has logged in successfully from this city before. The status must be "Success".

B.9.46 User: City First Time for User

General information about the User: City First Time for User condition is provided in the following table.

Table B-247 User: City First Time for User

Condition	User: City First Time for User
Description	Is the user using this city for the first time?
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: City First Time for User Parameters

The following table summarizes the parameters in the User: City First Time for User condition.

Table B-248 User: City First Time for User Parameters

Parameter	Description	Possible Values	Can be Null?
Is	Checks if the condition should return true or false if the user had logged in from this city before.	Default is True	No

This condition checks if the user has logged in from this city before.

B.9.47 User: Login for First Time

General information about the User: Login for First Time condition is provided in the following table.

Table B-249 User: Login for First Time

Condition	User: Login for First Time
Description	Checks if user is logging in for the first time
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

B.9.48 User: IP Carrier for First Time

General information about the User: IP Carrier for First Time condition is provided in the following table.

Table B-250 User: IP Carrier for First Time

Condition	User: IP Carrier for First Time
Description	Is the user using this IP carrier for the first time?
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: IP Carrier for First Time Parameters

The following table summarizes the parameters in the User: IP Carrier for First Time condition.

Table B-251 User: IP Carrier for First Time parameters

Parameter	Description	Possible Values	Can be Null?
Is	Checks if the condition should return true or false if the IP Carrier is the one specified.	Default is True	No

Use this condition to check whether the user has logged in successfully using this IP carrier before. The status must be "Success".

B.9.49 User: User IP for First Time

General information about the User: User IP for First Time condition is provided in the following table.

Table B-252 User: User IP for First Time

Condition	User: User IP for First Time
Description	This checks if the user has used this IP successfully previously
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: User IP for First Time Parameters

The following table summarizes the parameters in the User: User IP for First Time condition.

Table B-253 User: User IP for First Time Parameters

Parameter	Description	Possible Values	Can be Null?
Is First Time	Checks if IP has been used before.	Default is True	No

Use this condition to check whether the user has logged in successfully from this IP address before. The status must be "Success".

B.9.50 User: User ISP for First Time

General information about the User: User ISP for First Time condition is provided in the following table.

Table B-254 User: User ISP for First Time

Condition	User: User ISP for First Time
Description	This checks if the user has used this ISP successfully previously
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: User ISP for First Time Parameters

The following table summarizes the parameters in the User: User ISP for First Time condition.

Table B-255 User: User ISP for First Time

Parameter	Description	Possible Values	Can be Null?
First Time	Checks if the condition should return true or false if the ISP has been used successfully before.	Default is True	No

Use this condition to check whether the user has logged in successfully using this internet service provider before. The status must be "Success".

If the user has never logged in using this internet service provider, trigger the rule.

B.9.51 User: Check First Login Time

General information about the User: Check First Login Time condition is provided in the following table.

Table B-256 User: Check First Login Time

Condition	User: Check First Login Time
Description	Checks if user first logged in within range. First login is the first successful login
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Check First Login Time Parameters

The following table summarizes the parameters in the User: Check First Login Time condition.

Table B-257 User: Check First Login Time parameters

Parameter	Description	Possible Values	Can be Null?
First time login within	Value to watch for in first login	Default is 3	No
Time Unit	Time units to be associated with the First time login within parameter	Select time unit configured from the time.unit.enum property. Milliseconds, Seconds, Minutes, Hours, Days, Weeks, Months, Years	No
Before	Checks if first login is before the specified duration	False or True	No

B.9.52 User: ASN for First Time

General information about the User: ASN for First Time condition is provided in the following table.

Table B-258 User: ASN for First Time

Condition	User: ASN for First Time
Description	Is the user using this ASN for the first time?
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: ASN for First Time Parameters

The following table summarizes the parameters in the User: ASN for First Time condition.

Table B-259 User: ASN for First Time

Parameter	Description	Possible Values	Can be Null?
Is	This is a boolean parameter that defines a default return value if the user is using this ASN for the first time.	Default is True	No

Use this condition to check whether the user has logged in successfully using this ASN before. The status must be "Success".

B.9.53 User: User Carrier for First Time

General information about the User: User Carrier for First Time condition is provided in the following table.

Table B-260 User: User Carrier for First Time

Condition	User: User Carrier for First Time
Description	This checks to see if the user has used this carrier successfully previously
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: User Carrier for First Time Parameters

The following table summarizes the parameters in the User: User Carrier for First Time condition.

Table B-261 User: User Carrier for First Time

Parameter	Description	Possible Values	Can be Null?
First Time	Checks if the condition should return true or false if the carrier has been used successfully before.	True	No

Use this condition to check whether the user has logged in successfully using this carrier before. The status must be "Success".

B.9.54 User: Maximum Countries

General information about the User: Maximum Countries condition is provided in the following table.

Table B-262 User: User Carrier for First Time

Condition	User: Maximum Countries
Description	Number of countries within the given time period
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Maximum Countries Parameters

The following table summarizes the parameters in the User: Maximum Countries condition.

Table B-263 User: Maximum Countries Parameters

Parameter	Description	Possible Values	Can be Null?
More than	Maximum number of countries to watch for. If the country count exceeds this number within the duration with a certain status, then the condition will evaluate to true.	Default is 3	No
Within Duration (seconds)	Time period in seconds to look back into users session history.	[Integer] The 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
Authentication status	Authentication status	Authentication status is configured through auth.status.enum. For example: Blocked Locked Database Error Password Expired Invalid User Pending Pending activation Session expired Session reused Success System Error User is disabled Wrong answer Wrong password Wrong pin	No

B.9.55 User: Maximum States

General information about the User: Maximum States condition is provided in the following table.

Table B-264 User: Maximum States

Condition	User: Maximum States
Description	Number of states within the given time period
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Maximum States Parameters

The following table summarizes the parameters in the User: Maximum States condition.

Table B-265 User: Maximum States Parameters

Parameter	Description	Possible Values	Can be Null?
More than	Maximum number of states to watch for. If the state count exceeds this number within a duration, then the condition will evaluate to true.	Default is 3	No
Within Duration (seconds)	Time period in seconds to look back into users session history.	[Integer] The 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
Authentication status	Authentication status	Authentication status is configured through auth.status.enum. For example: Blocked Locked Database Error Password Expired Invalid User Pending Pending activation Session expired Session reused Success System Error User is disabled Wrong answer Wrong password Wrong pin	No

B.9.56 User: Maximum Cities

General information about the User: Maximum Cities condition is provided in the following table.

Table B-266 User: Maximum Cities

Condition	User: Maximum Cities
Description	Checks the number of cities within the given time period
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Maximum Cities Parameters

The following table summarizes the parameters in the User: Maximum Cities condition.

Table B-267 User: Maximum Cities Parameters

Parameter	Description	Possible Values	Can be Null?
More than	Maximum number of cities to watch for. If the number of cities exceeds the number within the duration with a certain authentication status, the condition triggers.	Default is 3	No
Within duration (seconds)	Time period in seconds to look back into users session history.	Default is 3600	No
Authentication status	Authentication status for which to check.	Authentication status is configured through the auth.status.enum property.	No

The condition is used to check the number of cities the user logged in from within the duration with a certain authentication status.

B.9.57 User: Maximum Locations Timed

General information about the User: Maximum Locations Timed condition is provided in the following table.

Table B-268 User: Maximum Locations Timed

Condition	User: Maximum Locations Timed
Description	Maximum number of locations within the given time period
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Maximum Locations Timed Parameters

The following table summarizes the parameters in the User: Maximum Locations Timed condition.

Table B-269 User: Maximum Locations Timed

Parameter	Description	Possible Values	Can be Null?
Location Attribute	Location characteristic	Used location attributes can be, for example: ASN Carrier Connection Type ISP Second level domain Top level domain	No
More than	Maximum number of locations to watch for. If the location count exceeds this number with the location attribute within a certain duration, then the condition will evaluate to true.	Default is 3	No
Within duration (seconds)	Time period in seconds to look back into users session history.	[Integer] The 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

B.9.58 User: Maximum IPs Timed

General information about the User: Maximum IPs Timed condition is provided in the following table.

Table B-270 User: Maximum IPs Timed

Condition	User: Maximum IPs Timed
Description	Maximum number of IP within the given time period
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Maximum IPs Timed Parameters

The following table summarizes the parameters in the User: Maximum IPs Timed condition.

Table B-271 User: Maximum IPs Timed Parameters

Parameter	Description	Possible Values	Can be Null?
More than	Maximum number of IP addresses to watch for. If the IP address count exceeds this number within a period, then the condition will evaluate to true.	Default is 3	No
Within	Within the time period	Default is 3600	No
Time	Time units to be associated with the Within parameter	Select a time unit configured in the enum time.unit.enum. Choices are: Milliseconds, Seconds, Minutes, Hours, Days, Weeks, Months, Years	No

B.9.59 User: Country Failure Count for User

General information about the User: Country Failure Count for User condition is provided in the following table.

Table B-272 User: Country Failure Count for User

Condition	User: Country Failure Count for User
Description	Check failure count for the user from the given country
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Country Failure Count for User Parameters

The following table summarizes the parameters in the User: Country Failure Count for User condition.

Table B-273 User: Country Failure Count for User Parameters

Parameter	Description	Possible Values	Can be Null?
Is Country First time?	Checks if the condition should return true or false if the country has not been used before.	Default is True	No
Failure count more than	Maximum number of failures to watch for in seconds. If the failure count exceeds this number in seconds, then the condition will evaluate to true.	Default is 2	No
in seconds	Seconds elapsed.	Default is 3600	No
If error, return	Value to return if there are any errors.	Default is False	Yes

Use this condition to check the number of times the user is failing login (incorrect password) from the same country.

B.9.60 User: Check Login Count

General information about the User: Check Login Count condition is provided in the following table.

Table B-274 User: Check Login Count

Condition	User: Check Login Count
Description	Check user login count within specified duration
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Check Login Count Parameters

The following table summarizes the parameters in the User: Check Login Count condition.

Table B-275 User: Check Login Count Parameters

Parameter	Description	Possible Values	Can be Null?
Check only current user	Condition to check for the current users	Default is True	No
Authentication status	Account status	Possible values are: Blocked Database Error Invalid User Locked Password Expired Pending Pending Activation Session Expired Session Reused Success System Error User Disabled Wrong Answer Wrong PIN Wrong Password	No
in seconds	Seconds elapsed	Default is 3600	No
with login more than	Maximum number of logins to watch for. If the login count exceeds this number, then the condition will evaluate to true.	Default is 5	No
If error, return	Value to return if error occurs.	Default is False	Yes
Consider current request or not	Consider the current request or not	Default is False	Yes

Use this condition if you want to check the user login count within specified duration.

B.9.61 User: Last Login Status

General information about the User: Last Login Status condition is provided in the following table.

Table B-276 User: Last Login Status

Condition	User: Last Login Status
Description	Checks to see if user login status is in specified list
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Last Login Status Parameters

The following table summarizes the parameters in the User: Last Login Status condition.

Table B-277 User: Last Login Status Parameters

Parameter	Description	Possible Values	Can be Null?
Check last login Within	Duration from login time	Default is 4	No
Time	Time unit to be associated with the Check last login within parameter	The time unit is from the enum time.unit.enum. Select from: Milliseconds, Seconds, Minutes, Hours, Days, Weeks, Months, Years	No
Ignore logins with status in	Ignore logins with Authentication Status in this group	Authentication status group
Trigger if last login status in	List of Authentication Status to Check	Authentication status

B.9.62 User: Last Login within Specified Time

General information about the User: Last Login within Specified Time condition is provided in the following table.

Table B-278 User: Last Login within Specified Time

Condition	User: Last Login within Specified Time
Description	Checks last login within specified time
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Last Login within Specified Time Parameters

The following table summarizes the parameters in the User: Last Login within Specified Time condition.

Table B-279 User: Last Login within Specified Time Parameters

Parameter	Description	Possible Values	Can be Null?
Within duration (seconds)	This parameter defines the period in which the last login attempts was made.	Default is 30	No
Is from different IP	Boolean parameter to decide if the default return value should be true or false if the login is from a different IP.	Default is False	No

B.9.63 User: Check Login Time

General information about the User: Check Login Time condition is provided in the following table.

Table B-280 User: Check Login Time

Condition	User: Check Login Time
Description	Checks if user login time is within the specified time
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Check Login Time Parameters

The following table summarizes the parameters in the User: Check Login Time condition.

Table B-281 User: Check Login Time Condition Parameters

Parameter	Description	Possible Values	Can be Null?
Trigger	If the Trigger parameter is set to True, the rule condition triggers if the condition is met. If the Trigger parameter is set to False, the rule condition will only trigger if the condition is not met.	Default is True	No
Above or Equal To Hour (0-23)	Lower bound of hour of the day, values between 0 and 23	Default is 9	No
Below Hour (0-23)	Upper bound of hour of the day, values between zero and 23	Default is 18	No

B.9.64 User: Login Time Between Specified Times

General information about the User: Login Time Between Specified Times condition is provided in the following table.

Table B-282 User: Login Time Between Specified Times

Condition	User: Login Time Between Specified Times
Description	Login time between specified time
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Login Time Between Specified Times Parameters

The following table summarizes the parameters in the User: Login Time Between Specified Times condition.

Table B-283 User: Login Time Between Specified Times

Parameter	Description	Possible Values	Can be Null?
From time	Beginning of time range	Default is 2:00	No
To time	End of time range	Default is 4:00	No
Try Location Based Time Zone	Timezone	Default is False	No

This condition checks if the user logged in during a specified time range.

If the useTimeZone parameter is set to true then OAAM uses the time based on desktop time, as provided by the IP Location data.

For example, this condition checks if the time is between 1 PM and 2 PM.

If you set the useTimeZone parameter to true, then OAAM will try to see if it is between 1 PM and 2PM in the user's geographical location, based on IP location data.

B.9.65 User: Is Last IP Match with Current IP

General information about the User: Is Last IP Match with Current IP condition is provided in the following table.

Table B-284 User: Is Last IP Match with Current IP

Condition	User: Is Last IP Match with Current IP
Description	Checks if user login IP address matches with that of previous login
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Is Last IP Match with Current IP Parameters

The following table summarizes the parameters in the User: Is Last IP Match with Current IP condition.

Table B-285 User: Is Last IP Match with Current IP Parameters

Parameter	Description	Possible Values	Can be Null?
is	Boolean parameter to decide if the default return value should be true or false if the IP address matches.	Default is False	No
Class C Match (False, if full IP match)	Class C IP address. Each Class C network address has a 24-bit network prefix, with the three highest order bits set to 1-1-0 and a 21-bit network number, followed by an 8-bit host number.	Default is True	No
Within duration (seconds)	Time period in seconds to look back into users session history.	[Integer] The 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 a negative value is provided for this parameter then condition will always evaluate to false.	No
Default Return Value	Default return value, in case the login is not found in specified time period or in case of error.	[False] / True	No

B.9.66 User: Location Used Timed

General information about the User: Location Used Timed condition is provided in the following table.

Table B-286 User: Location Used Timed

Condition	User: Location Used Timed
Description	If user used this location within the given time period
Prerequisites	None for the condition as such, but you must have a rule configured with this condition to experience the behavior.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Location Used Timed Parameters

The following table summarizes the User: Location Used Timed condition parameters.

Table B-287 User: Location Used Timed Condition Parameters

Parameter	Description	Possible Values	Can be Null?
Is	Checks if the condition should return true or false if the user used this location within a given time period.	Default is True	No
Used Location (Attribute)	The location attribute	Use condition attributes are as follows: ASN Carrier Connection type ISP Metro Second level domain Top level domain City Country IP routing type State	No
Within	This parameter defines the short period in which the location is used.	Default is 3600	No
Time	Time unit to be associated with the Within parameter.	The time unit is from the enum time.unit.enum. Select from: Milliseconds, Seconds, Minutes, Hours, Days, Weeks, Months, Years	No
Minimum Records Needed for the Check	Checks if number of records are met	Default is 1	No

B.9.67 User: Checkpoint Score

The following table provides general information about the User: Checkpoint Score condition.

Table B-288 User: Checkpoint Score

Condition	User: Checkpoint Score
Description	Checks if the score is within limits
Prerequisites	None for the condition as such, but you must have a rule configured with this condition.
Assumptions	None
Available since version	10.1.4.5
Checkpoints	All checkpoints

User: Checkpoint Score Condition Parameters

Table B-289 describes the parameters in the User: Checkpoint Score condition.

Table B-289 User: Checkpoint Score Condition Parameters

Parameter	Description	Possible Values	Can be Null?
Checkpoint (optional)	Checkpoints from a list of checkpoints	Possible values are configured through the profile.type.enum property.	Yes
Score Above or equal to	Minimum score	Default is 500	No
And below or equal to	Maximum score	Default is 1000	No
Trigger	If the Trigger parameter is set to True, the rule condition triggers if the condition is met. If the Trigger parameter is set to False, the rule condition will only trigger if the condition is not met.	Default is True	No
If multiple executions, pick	Choose a score if there are multiple executions	Select from the following: Any score Last Max score Min score	No