Oracle® Adaptive Access Manager Administrator's Guide Release 10g (10.1.4.5) Part Number E12055-03 |
|
|
View PDF |
This appendix provides information about the conditions available standard on Oracle Adaptive Access Manager.
Descriptions for a few of the conditions are provided below.
Condition | DEVICE: Browser header substring |
---|---|
Description | Checks whether the supplied string exists as a substring in the browser's header information. String comparison is performed by ignoring the case (upper- or lowercase) of the strings. |
Pre-Requisites | |
Assumptions | You should have this rule configured through a model. |
Available since version | Pre-10.1.4.5 |
Runtimes | All Runtimes. |
Parameters
Parameter | Description | Possible Values | Can be Null? |
---|---|---|---|
subString | Substring which is to be checked with the string present in the browser. | Yes |
Possible User Scenarios
This condition can be potentially used to determine if the user is coming in from a particular version of a browser that is prone to security problems.
Condition | DEVICE: Device firsttime for user |
---|---|
Description | Checks if user is using this device for the first time ever. Please note that device is the combination of the physical device and the browser in most of the test scenarios. Please check the recent logins page to determine the device id associated with the login sessions to verify the rule. The user's current (session) device is also counted as when found to be used for the first time. |
Pre-Requisites | You should have this rule configured through a model. |
Assumptions | |
Available since version | Pre-10.1.4.5 |
RunTimes | All Runtimes. |
Parameters
Parameter | Description | Possible Values | Can be Null? |
---|---|---|---|
is | Boolean that checks if the condition should return true or false if the user is using this device for the first time | true (default) or false | Cannot be Null. |
Possible User Scenarios
This condition can be potentially used to determine if the user is coming in from a different device or different devices and then challenge him if it is the case.
Condition | DEVICE: In Group |
---|---|
Description | Checks to see if this device is in the specified list. |
Pre-Requisites | There should be a list defined already which has devices (ids) as members. You should have this rule configured through a model. |
Assumptions | |
Available since version | 10.1.4.5 |
Runtimes | All Runtimes. |
Parameters
Parameter | Description | Possible Values | Can be Null? |
---|---|---|---|
isInList | This is a boolean parameter that defines a default return value if the device is in the list. | True / [False] | Yes. |
listId | This is the list of ids of a list of devices. The model-rule interface will show you a menu of the possible lists of device lists. Please use the group editor in Adaptive Risk Manager to edit the device list. | Yes |
Possible User Scenarios
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 have certain devices— those that can be deemed as compromised—and you may want to block users coming in from the device or you may not want the users to perform certain activities if they are coming in from a device that is a kiosk etc.
Condition | DEVICE: Excessive Use |
---|---|
Description | Checks to see if this device is used excessively. Basically, checks if a device was not active (not used) for a number of days and suddenly a large number of users is coming in from the same device in a short period of time (in a few hours). This condition can be potentially used to track the compromised device of some automated programs that obtained access to the code and then tries to login a number of users from there. |
Pre-Requisites | You should have this rule configured through a model. |
Assumptions | |
Available since version | 10.1.4.5 |
RunTimes | All Runtimes. |
Parameters
Parameter | Description | Possible Values | Can be Null? |
---|---|---|---|
userCount | Number of users coming in from a single device in a short period of time. | positive integers | No |
withInHours | This parameter defines the short period of time in which we have to find the excessive use. | positive integer | No |
notInDays | This is the parameter that describes how many days the device was not in use. | positive integer | No |
Possible User Scenarios
This condition can be potentially used to determine if the device of the current activity is compromised. For example, you might have certain devices—those which can be deemed as compromised—and you may want to block users coming in from there. This could be, for example, somebody hacking into a bank computer and then tries to perform various activities. Typically, you would not have activity coming in from that computer for several days.
Condition | DEVICE: Is registered |
---|---|
Description | Condition checks if the device from where user is coming in is registered for the user. |
Pre-Requisites | You should have this rule configured through a model. |
Assumptions | |
Available since version | 10.1.4.5 |
RunTimes | All Runtimes. |
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 device is registered. | [True] / False | Yes |
Possible User Scenarios
This condition can be used to identify if the user is coming in from a device that he has not registered before. This can basically prevent a fraud where users login information is stolen and the thief tries to login this user from some another otherwise safe location.
Condition | DEVICE: User count |
---|---|
Description | Check to see if this device is used by a number of 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 number of users. |
Pre-Requisites | You should have this rule configured through a model. |
Assumptions | |
Available since version | 10.1.4.5 |
RunTimes | All Runtimes. |
Parameters
Parameter | Description | Possible Values | Can be Null? |
---|---|---|---|
numberOfUsers | Number of users coming in from the same device in a short period of time. | positive integers | No |
withinSeconds | This parameter defines the short period of time in which the numbers user try to login into the system using that device. | positive integer | No |
Possible User Scenarios
This condition can be potentially used to determine if the device of the current activity is compromised. This could also mean that somebody stole login information for a number of users and then sat down to ruin there accounts. This will result in a lot of users coming in from same device in an interval of a few seconds.
Condition | DEVICE: Timed not status |
---|---|
Description | This condition counts the attempts by users from the same device (the device from which this attempt is coming in) in the last few seconds whose 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. |
Pre-Requisites | You should have this rule configured through a model. |
Assumptions | |
Available since version | 10.1.4.5 |
RunTimes | All Runtimes. |
Parameters
Parameter | Description | Possible Values | Can be Null? |
---|---|---|---|
status | We want to count the attempts with the status that is not equal to this status. | auth.status.enum (auth.status.enum.success is the default) | No |
withinSeconds | This parameter defines the short period of time in which the number of login attempts into the system using that device are to be counted. | positive integer | No |
attempts | Max number of attempts that we want to watch for. If the attempt count in the ARM exceeds this number then condition will evaluate to true. | positive integer | No |
Possible User Scenarios
This condition can be potentially used to determine if the device of the current activity is compromised. The possibility of fraud that can be detected here is someone (or a automated program) is using the same device to make login attempts and they are either failing or passing based on what data the thieves have stolen. Or may be some program is trying to break the password for user in an automated fashion. In these cases you would see repeated failed login attempt from the same device in a short amount of time.
Condition | DEVICE: Timed not status |
---|---|
Description | This condition counts the attempts by users from the same device (the device from which this attempt is coming in) in the last few seconds whose 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. |
Pre-Requisites | You should have this rule configured through a model. |
Assumptions | |
Available since version | 10.1.4.5 |
RunTimes | All Runtimes. |
Parameters
Parameter | Description | Possible Values | Can be Null? |
---|---|---|---|
status | We want to count the attempts with the status that is not equal to this status. | auth.status.enum (auth.status.enum.success is the default) | No |
withinSeconds | This parameter defines the short period of time in which the number of login attempts into the system using that device are to be counted. | positive integer | No |
attempts | Max number of attempts that we want to watch for. If the attempt count in Adaptive Risk Manager exceeds this number then condition will evaluate to true. | positive integer | No |
Possible User Scenarios
This condition can be potentially used to determine if the device of the current activity is compromised. The possibility of fraud that can be detected here is someone (or a automated program) is using same device to make login attempts and they are either failing or passing based on what data the thieves have stolen. Or may be some program is trying to break the password for user in automated fashion. In these cases you would see repeated failed login attempt from same device in short amount of time.
Condition | DEVICE: Velocity from last login |
---|---|
Description | Condition evaluates if the users velocity in miles per hour is more than specified value. Location database is used to determine the location of the user for this login and previous login. Takes into account the current session also. Please note that the velocity calculation is highly dependent on accuracy of location data. |
Pre-Requisites | You should have this rule configured through a model. Location database should be loaded to have correct behavior of this rule. You might also need tools (like browser header modifier plugin) to simulate the different IP for the incoming session. |
Assumptions | Location database is loaded. |
Available since version | 10.1.4.5 |
RunTimes | All Runtimes. |
Parameters
Parameter | Description | Possible Values | Can be Null? |
---|---|---|---|
milesPerHour | Positive number that indicates users speed in miles per hour. If condition determines that user has travelled faster than this value then condition will evaluate to true. | positive integer (default = 60) | No |
sinceSeconds | This is a parameter that is a positive integer that specifies the time difference between this login and last login to calculate users velocity. | positive integer (default = 172800 which is 48 hours) | No |
Possible User Scenarios
This condition can be used to determine users's location and risk it poses because of changes in user's login location from time to time.
One of the simplest scene is when user is traveling by ground transportation, you can configure this rule to be having typically having miles per hour as 60 and time to be in seconds (use default values).
Other case could be users traveling on air transport. Here you can use different values (say 500 miles an hour) to make sure that login locations and speed are reasonable behavior.
However we should be aware that the velocity calculation depend highly on location databases.
Condition | ENTITY: Entity is member of pattern bucket for firsttime in certain time period |
---|---|
Description | Condition to check if this Entity is member of pattern bucket for firsttime in certain time period. First time is kind of a relative function here. So if you want to really track first time, then in rule / model configuration user years as the time period type and use a long value like 5 years or so. |
Pre-Requisites | You should have entities and patterns defined before you try to add this to rule / model. |
Assumptions | Auto Learning is enabled. |
Available since version | 10.1.4.5 |
RunTimes | All Runtimes. |
Parameters
Parameter | Description | Possible Values | Can be Null? |
---|---|---|---|
Pattern Name for bucket firsttime | Name of the pattern for whose bucket firsttime is to be checked. | Cannot be null. | |
Is Condition true | Evaluate this condition to true if this parameter is true and firsttime bucket is true. | Cannot be null | |
Time period type for bucket membership | The time period Type (hours, days, months of years) | One of wotk.type.enum. That is (hour, day, month, year) | Cannot be null. |
Time period for bucket membership | The time period over which the pattern membership is to be evaluated. This is just units of time | positive number. (Try to use sensible numbers depending on time period type). Use 0..24 for hours, use 1 through 12 for months, 1 through 31 for days, and 1 through 8 for years. | Cannot be null |
Member type for pattern-bucket 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. | Cannot be null. |
First time Count | The count of occurrences against which to compare | If you are using this rule in Pre-Auth (or pre-transaction) scenario then use value of 0 here since auto learning takes place on trailing edge of authentication or transaction. For all other runtimes use value of 1 for this parameter. (1 is also a default value) | Cannot be null |
Possible User Scenarios
Here are couple of examples of how to make use of this condition.
1] This condition can be potentially used in coming out with a first time rules. As an example define a user (city for each) pattern and attach this pattern to this condition based rule in a model. So when user comes in from a city first time, rule will be triggered.
2] This can be used for challenge users when they do something for first time in transactions also. For example user tried to do a bill transfer of 5000 dollars. This can be achieved using pattern that has user (transaction amount ranges 1..100, 1000...10000 etc.
Condition | ENTITY: Entity is member of pattern less than some percent times in given time period. |
---|---|
Description | Condition to check if this Entity is member of pattern bucket for less than certain percent in certain time period.This condition checks the pattern membership percent against the pattern usage of same entity. Here we will be counting entity's membership count for percentage and not the number of entities that belong to that pattern. |
Pre-Requisites | You should have entities and patterns defined before you try to add this to rule / model. |
Assumptions | Auto Learning is enabled. |
Available since version | 10.1.4.5 |
RunTimes | All RunTimes |
Parameters
Parameter | Description | Possible Values | Can be Null? |
---|---|---|---|
Pattern Name | Name of the pattern-bucket for whose percentage is to be checked. | Cannot be null | |
Is Condition true | Evaluate this condition to true if this parameter is true and the pattern percent is less than the given value | Cannot be null | |
Time period type for bucket membership | The time period Type (hours, days, months of years) | One of wotk.type.enum. That is (hour, day, month, year) | Cannot be null. |
Time period for bucket membership | The time period over which the pattern membership is to be evaluated. This is just units of time | positive number. (Try to use sensible numbers depending on time period type). Use 0..24 for hours, use 1 through 12 for months, 1 through 31 for days, and 1 through 8 for years. | Cannot be null |
Member type for pattern-bucket 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. | Cannot be null. |
patternHitPercent | The percentage to be compared. | Here again make sure you pass good values. Providing values in decimal points may not be a good idea. Since the percentage values may be Double type of values when calculated over a large number of login an pattern usage combination. So try to keep away from entering 10.45362. Rather go for 10.5 or I would suggest even just use 10 or 11 if you are not very picky about the exact number. | Cannot be null |
Possible User Scenarios
This can be most effectively used in tracking user's own habits. Examples can be if user usually login from certain state and he started using other couple of states also. In that case he will be challenged on first few times he logs in from those states since his percentage for those state will be lower than say 10%. User (for each state) pattern can be used to achieve this.
Condition | ENTITY: Entity is member of pattern bucket less than some percent with all entities in picture |
---|---|
Description | Condition to check if this Entity is member of pattern bucket some percent of time as compared to all other entities that have been member of this pattern. This condition takes into account all the other entities, so while making use of this condition, there will be obviously a bit of performance hit as compared to some simpler conditions. |
Pre-Requisites | You should have entities and patterns defined before you try to add this to rule / model. |
Assumptions | Auto Learning is enabled. |
Available since version | 10.1.4.5 |
RunTimes | All RunTimes |
Parameters
Parameter | Description | Possible Values | Can be Null? |
---|---|---|---|
Pattern Name | Name of the pattern for whose bucket percentage is to be checked. | Cannot be null. | |
Is Condition true | Evaluate this condition to true if this parameter is true and percentage is less than the specified percentage. | Cannot be null | |
Time period type for bucket membership | The time period Type (hours, days, months of years) | One of wotk.type.enum. That is (hour, day, month, year) | Cannot be null. |
Time period for bucket membership | The time period over which the pattern membership is to be evaluated. This is just units of time. | positive number. (Try to use sensible numbers depending on time period type). Use 0..24 for hours, use 1 through 12 for months, 1 through 31 for days, and 1 through 8 for years. | Cannot be null |
Member type for pattern-bucket 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. | Cannot be null. |
percentHitCount | The percentage which we want to compare against. | Try to use a sensible number here. Use 10 or 11 in place of 10.7623591 as an example. | Cannot be null |
Possible User Scenarios
This condition can be used to find out if users are doing something that is not in line with other using doing. For example user coming from a city that usually most users don't come in from.
Non popular states, cities, non-popular IPs etc. can be implemented using these condition.
Condition | ENTITY: Entity is member of pattern N times |
---|---|
Description | Condition to check if this Entity is member of pattern n number of times in last some time period. |
Pre-Requisites | You should have entities and patterns defined before you try to add this to rule / model. |
Assumptions | Auto Learning is enabled. |
Available since version | 10.1.4.5 |
RunTimes | All Runtimes, see the note for Pre-Auth though. |
Parameters
Parameter | Description | Possible Values | Can be Null? |
---|---|---|---|
Pattern Name | Name of the pattern for whose bucket bucket membership is to be checked. | Cannot be null. | |
patternHitCountForUser | The hit count which will be compared against. If hit count for the pattern is more than this value then condition returns true. | For Pre-Auth execution set the count one less than what you want the rule to trigger on. | Cannot be null |
Time period type for bucket membership | The time period Type (hours, days, months of years) | One of wotk.type.enum. That is (hour, day, month, year) | Cannot be null |
Time period for bucket membership | The time period over which the pattern membership is to be evaluated. This is just units of time | positive number. (Try to use sensible numbers depending on time period type). Use 0..24 for hours, use 1 through 12 for months, 1 through 31 for days, and 1 through 8 for years. | Cannot be null |
Member type for pattern-bucket 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. | Cannot be null. |
isMoreThan | Boolean value that is used to return true or false from condition. It works as below if (isMoreThan == true) and (hitCountMorethan returned true) then condition evaluates to true. ELSE if (isMoreThan == false) and (hitCountMorethan returned false) then condition evaluates to false. and condition evaluates to false in all other cases. | Cannot be null |
Possible User Scenarios
This can be used to see if user performed a particular operation a few times, which was well defined. For example if user came in from a group of IP that are tagged as anonymizer. If user does it few times then model can be configured to take some action.
Condition | ENTITY: Entity is member of bucket N times in a given time period |
---|---|
Description | Condition to check if this Entity is a member of the bucket a number of times in a given time period. This condition can be used to check the current behavior against the pattern. Please note that this is a count-based condition. So, if you configure to trigger it, for example, for a count less than three, it will trigger on the first login that matches the fingerprint. |
Pre-Requisites | Ensure that the following pre-requisites are met:
|
Assumptions | Auto-Learning is enabled. |
Available since version | 10.1.4.5.2 |
Runtimes | All runtimes see the note for pre-auth though. |
Parameters
Parameter | Description | Possible Values | Can be Null? |
---|---|---|---|
Pattern Name | Name of the pattern for whose bucket membership is to be checked. In the rule / model UI select it from a drop down of active patterns that will be presented. | Cannot be null. | |
Time period for bucket membership | The time period over which the bucket membership is to be evaluated. This is in units of time. | Use 1 thru 23 for hours. 1 thru 30 for days. 1 thru 12 for months and 1 thru 8 for years. Server will use the use the max values if you enter values more than the above specified. | Cannot be null |
Time period type for bucket membership | The time period Type (hours, days, months of years) | One of workflow.type.enum. That is (hour, day, month, year) | Cannot be null |
Member type for pattern-bucket 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. | Cannot be null |
BucketHitCountForEntity | The hit count which will be compared against. Hit count for the bucket and the compare operator described below evaluate the outcome of the condition together. | For Pre-auth execution set the count one less than what you want the rule to trigger on. | Cannot be null |
compareOperator | Comparison operator to be used for comparing the count in the system with bucketHitCountForEntity. For example if you passed compareoperator as "less_than" and bucketHitCount as 3. Then if in the system the condition will evaluate to true as ling as hit count for that bucket is less than 3 for that authentication. | Possible values are picked up from enum bharosa.numeric.eval.operator.enum
equal_to not_equal_to less_than less_than_or_equal_to more_than more_than_or_equal_to are the possible values. |
Cannot be null. |
successReturnValue | Value to return if the condition evaluates to true. If condition does not evaluate to true then opposite of the success value will be returned. | True / False. | Cannot be null |
errorReturnValue | This is the value that will returned if the condition execution runs into issue. Some of the possible errors that it can run into is, pattern is not active, the parameters that were passed (configured) are incorrect or do not have the values in the expected range. | True / False. | Cannot be null. |
Possible User Scenarios
This condition can be used to check if the user performed a particular operation a few times, which was well defined. For example if a user came in from a city for a few times, we can use this information to challenge the user for the first few times.
Condition | LOCATION: ASN in group |
---|---|
Description | Check 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. |
Pre-Requisites | There should a list of ASNs already defined. You should have this rule configured through a model. |
Assumptions | |
Available since version | |
RunTimes | All Runtimes. |
Parameters
Parameter | Description | Possible Values | Can be Null? |
---|---|---|---|
isInList | This is a boolean parameter that defines a default return value if the ASN is in the list. | [True] / False | Yes. |
listId | This is a list id of the list of ASNs. The model -rule user interface will show you a menu of possible lists of ASNs to configure for this parameter. Please use group editor in Adaptive Risk Manager to edit the ASN list. | Yes |
Possible User Scenarios
This condition can be potentially used to determine if the ASN of the current activity (IP) belongs to a particular list of ASNs. For example you might have certain ASNs those can be deemed as dangerous and you may want to block users coming in from there. Or you might not want users to do certain activity if they are coming in from an ASN that is from a particular country or region.
Condition | LOCATION: IP in Range group |
---|---|
Description | Checks whether the IP of the current activity belongs to a list of IP-ranges specified. |
Pre-Requisites | There should a group defined already which has IP-ranges as members. You should have this rule configured through a model. |
Assumptions | |
Available since version | 10.1.4.5.1 |
RunTimes | All Runtimes. |
Parameters
Parameter | Description | Possible Values | Can be Null? |
---|---|---|---|
isIPInRangeGroup | This is a boolean parameter that defines a default return value if the IP is really in range group. | [True] / False | Yes. |
ipRangeListId | This is a list id of the list of IP-ranges. The model -rule GUI will show you a menu of possible lists of IP-ranges. Please use group editor in Adaptive Risk Manager to edit this group list. | Yes |
Possible User Scenarios
This condition can be potentially used to determine if the IP of the current activity belongs to one of several ranges of IPs that may be of interest. For example you might have ranges of IPs coming in from particular subnet and you might want to take some action if that is the case.
Note:
The filter operators "like" and "not like" work only on transaction data and entity data where the data type is string.Condition | TRANSACTION: Check Current Transaction Using Filter |
---|---|
Description | Check to see if the current transaction matches ALL the conditions specified. Up to 6 conditions can be specified. |
Pre-Requisites |
|
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 |
RunTimes | All Runtimes. |
Parameters
Parameter | Description | Possible Values | Can be Null? |
---|---|---|---|
trxDefKey | Transaction type of the transaction to be counted. It represents the Transaction Definition fully qualified key. This is specified using the list box that has the list of transaction definitions | No | |
filter1Key
filter2Key filter3Key filter4Key filter5Key filter6Key |
These parameters specify the left hand side of the filter conditions. The left hand side represents the fully qualified key of the transaction field.
This field could be an entity field or data field or transaction attribute or request attribute. |
Yes | |
filter1Condition
filter2Condition filter3Condition filter4Condition filter5Condition filter6Condition |
These parameters represent the operator and right hand side of the filter condition. The operator and the right hand side represent the fully qualified key of the filter condition.
The right hand side is the value, which could be a simple value, the value of the current transaction, or a group.
|
Wherever the filterKey is specified, an appropriate condition has to be specified |
Possible User Scenarios
This condition can be used whenever you want to trigger some 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).
For achieving this, you need to use this rule with two filter conditions. One for checking if the amount field is greater than 1000 and the second filter condition for checking if the country of the current session is in the list of High Risk countries.
This condition can be used to specify up to six (6) filter conditions on the current transaction.
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 etc. |
Pre-Requisites |
|
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 |
RunTimes | All Runtimes. |
Parameters
Parameter | Description | Possible Values | Can be Null? |
---|---|---|---|
trxDefKey | Transaction type of the transaction to be counted. It represents the Transaction Definition fully qualified key. This is specified using the list box that has the list of transaction definitions | No | |
specifiedConditionEnumForCount | Operator to be applied for the count condition. Specify greater than, greater than or equals, less than, less than or equals | No | |
specifiedValueForCount | Transaction count numeric value to check | No | |
durationDescriptor | Specify the duration during which the transactions have to be counted. The duration descriptor allows you to specify the duration.
Important: By default, durationType is "rolling," meaning it takes the current time as the end point to count backwards to the start point. Whenever the duration is described as "last" x seconds/minutes/hours/days, the rolling type duration has to be used. So if you specify 1 day using "rolling" durationType, the "rolling" day starts 24 hours (exactly 1 day) from the current time. For example, if it is 11:33 am, and you specify 1 day, the "rolling" day will start from 11:33 am of the previous day and end at the current time today. There will be occasions where you want to have the duration window start at 0.00. For those occasions, you should use the durationType as "calendar". So if you specify 1 day using "calendar" as the durationType, the "calendar" day will start at 0.00 (12:00 am) of that day and end at the current time. Examples of "rolling" and "calendar": A "calendar" week starts from Sunday regardless of the current day, whereas the "rolling" week starts from 7 days from the current day. A "calendar" month starts from the 1st of the current month, whereas the "rolling" month starts from the same day of the previous month. A "calendar" year starts from January 1st of the current year, whereas the "rolling" year starts from the same day of the previous year. In both the "calendar" and "rolling," the end date/time is the current time. The durationType affects how the startTime of the duration is computed. The "Before" option is used when you want to skip over an interval of time before you begin counting backwards to the start point. For example, if you want to calculate 7 days worth of data, but you do not want the data from the last 7 days, you would specify the interval of time you want to skip. If today is February 6, and you want to look at data from January 17 to the 23rd, you would specify "Before" 15 days. |
No | |
transactionStatusEnum | Specify the transaction status that has to be considered for counting.
Do not specify any status if you want to consider all transactions regardless of their status. |
Yes | |
ignoreCurrentTransactionInCount | Specify if you want to ignore the current transaction (if any) in the count.
If there are multiple transactions and if this is specified as true, only the last transaction is ignored. |
Yes | |
applyFilterOnCurrentTransaction | Specify if you want to check the filter conditions on the current transaction before performing the count.
If the filter conditions fail on the current transaction, then the rule condition is evaluated to false without performing the count. |
||
filter1Key
filter2Key filter3Key filter4Key filter5Key filter6Key |
These parameters specify the left hand side of the filter conditions. The left hand side represents the fully qualified key of the transaction field.
This field could be an entity field or data field or transaction attribute or request attribute. |
Yes | |
filter1Condition
filter2Condition filter3Condition filter4Condition filter5Condition filter6Condition |
These parameters represent the operator and right hand side of the filter condition. The operator and the right hand side represent the fully qualified key of the filter condition.
The right hand side is the value, which could be a simple value, the value of the current transaction, or a group.
|
Wherever the filterKey is specified, appropriate condition has to be specified |
Possible User Scenarios
This condition can be used whenever you want to trigger some rule based on transaction count 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 amount > 1000 for each purchase) from a high risk country, you may want to use this condition.
For achieving this, you need to use this rule with the following:
Specify Count condition as 'Greater Than Equals'
Specify Count to check as '2'
Specify the duration with durationType as rolling and duration as 1 hour
Specify false for "Ignore Current Transaction in count?" since you want to consider current transaction in count
Specify true for "Apply FilterOnCurrentTransaction?" field
Two filter conditions.
One for checking if the amount field is greater than 1000
and the second filter condition for checking if the country of the current session is in the list of High Risk countries.
This condition can be used to specify up to six (6) filter conditions that are applied on transactions that are considered for counting
Condition | TRANSACTION: CheckTransactionAggregrateAndCountUsingFilter.xml |
---|---|
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 etc. |
Pre-Requisites | 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 |
RunTimes | All Runtimes. |
Parameters
Parameter | Description | Possible Values | Can be Null? |
---|---|---|---|
aggregrateFunctionEnum | Aggregrate function to check. Available functions are sum, min, max, avg | ||
elementDefFQKey | Numeric element on which aggregrate check has to be performed. It represents fully qualified key of the numeric field. This is specified using list box that has list of all numeric data fields. | No | |
specifiedConditionEnumForAggregrate | Operator to be applied for the aggregrate condition. Specify greater than, greater than or equals, less than, less than or equals | No | |
specifiedValueForAggregrate | Aggregrate numeric value to check | No | |
specifiedConditionEnumForCount | Operator to be applied for the count condition. Specify greater than, greater than or equals, less than, less than or equals | Yes | |
specifiedValueForCount | Transaction count numeric value to check | Yes | |
durationDescriptor | Specify the duration during which the transactions have to be counted. The duration descriptor allows you to specify the duration.
Important: By default, durationType is "rolling," meaning it takes the current time as the end point to count backwards to the start point. Whenever the duration is described as "last" x seconds/minutes/hours/days, the rolling type duration has to be used. So if you specify 1 day using "rolling" durationType, the "rolling" day starts 24 hours (exactly 1 day) from the current time. For example, if it is 11:33 am, and you specify 1 day, the "rolling" day will start from 11:33 am of the previous day and end at the current time today. There will be occasions where you want to have the duration window start at 0.00. For those occasions, you should use the durationType as "calendar". So if you specify 1 day using "calendar" as the durationType, the "calendar" day will start at 0.00 (12:00 am) of that day and end at the current time. Examples of "rolling" and "calendar": A "calendar" week starts from Sunday regardless of the current day, whereas the "rolling" week starts from 7 days from the current day. A "calendar" month starts from the 1st of the current month, whereas the "rolling" month starts from the same day of the previous month. A "calendar" year starts from January 1st of the current year, whereas the "rolling" year starts from the same day of the previous year. In both the "calendar" and "rolling," the end date/time is the current time. The durationType affects how the startTime of the duration is computed. The "Before" option is used when you want to skip over an interval of time before you begin counting backwards to the start point. For example, if you want to calculate 7 days worth of data, but you do not want the data from the last 7 days, you would specify the interval of time you want to skip. If today is February 6, and you want to look at data from January 17 to the 23rd, you would specify "Before" 15 days. |
No | |
transactionStatusEnum | Specify the transaction status that has to be considered for counting. If you want to consider all transactions regardless of their status, do not specify any status | Yes | |
ignoreCurrentTransactionInCount | Specify if you want to ignore current transaction (if any) in the count. If there are multiple transactions and if this is specified as true, only the last transaction is ignored. | Yes | |
applyFilterOnCurrentTransaction | Specify if you want to check the filter conditions on the current transaction before performing the count. If the filter conditions fail on the current transaction then the rule condition is evaluated to false without performing the count. | ||
filter1Key
filter2Key filter3Key filter4Key filter5Key filter6Key |
These parameters specify the left hand side of the filter conditions. The left hand side represents the fully qualified key of the transaction field.
This field could be an entity field or data field or transaction attribute or request attribute. |
||
filter1Condition
filter2Condition filter3Condition filter4Condition filter5Condition filter6Condition |
These parameters represent the operator and right hand side of the filter condition. The operator and the right hand side represent the fully qualified key of the filter condition.
The right hand side is the value, which could be a simple value, the value of the current transaction, or a group.
|
Wherever the filterKey is specified, appropriate condition has to be specified |
Possible User Scenarios
This condition can be used whenever you want to trigger some rule based on aggregrate of a transaction numeric value and transaction count.
This is designed to reduce 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 lot of purchases (for example, more than 2 per hour with average amount > 500) from a high-risk country.
For achieving this, you need to use this rule with the following:
Specify Aggregrate condition as 'Average'
Specify Aggregrate value to check as '500'
Specify Count condition as 'Greater Than Equals'
Specify Count to check as '2'
Specify the duration with durationType as rolling and duration as 1 hour
Specify false for "Ignore Current Transaction in count?" since you want to consider current transaction in count
Specify true for "Apply FilterOnCurrentTransaction?" field
One filter condition: for checking if the country of the current session is in the list of High Risk countries.
This condition can be used to specify up to six (6) filter conditions that are applied on transactions that are considered for counting
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 if 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. |
Pre-Requisites | 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 |
RunTimes | All Runtimes. |
Parameters
Parameter | Description | Possible Values | Can be Null? |
---|---|---|---|
trxDefKey | Transaction Definition fully qualified key. This is specified using list box that has list of transaction definitions | No | |
elementDefFQKey | Transaction Entity/Element that needs to be counted for checking | No | |
durationDescriptor | Duration Descriptor | No | |
forTheSameCurrentUserId | Boolean flag to indicate whether only transactions belonging to the current user to be counted or not | Yes | |
ignoreCurrentTransactionInCount | Flag to indicate if the current transaction has to be ignored in the count | ||
specifiedConditionEnumForCount | Condition for the count check. Select only valid operators that are relevant to numeric values | No | |
specifiedValueForCount | Count value to check. Specify only valid positive integers. | No | |
applyFilterOnCurrentTransaction | Flag to indicate if the filter conditions have to validated on current transaction before doing the count | No | |
filter1Key
filter2Key filter3Key filter4Key filter5Key filter6Key |
These parameters specify the left hand side of the filter conditions. It represents fully qualified key of the transaction field.
This field could be an entity field or data field or transaction attribute or request attribute. Note: There is a widget for this that renders list box with all the data fields. |
Yes | |
filter1Condition
filter2Condition filter3Condition filter4Condition filter5Condition filter6Condition |
These parameters represent the operator and right hand side of the filter condition. It represents fully qualified key of the filter condition.
Note: There is a widget for this that renders the list box of operators and a way to specify simple value or group name (in case of IN or NOT IN operator) or select another field in the transaction. |
Wherever the filterKey is specified, appropriate condition has to be specified |
Possible User Scenarios
This condition can be used whenever you want to trigger a rule based on the count of an entity or entity/data element of the transaction.
For example, you have configured a transaction called purchase and you 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,
Select the "Credit Card" "Entity" name as the one to be counted, so that the rule counts the distinct number of credit cards used
Then select "For the same current user" flag as true.
Then select the duration as 2 Rolling hours and 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.
Condition | TRANSACTION: Check if consecutive Transactions in given duration satisfy the filter conditions |
---|---|
Description | Check if consecutive transactions in a given duration satisfy the specified filter conditions |
Pre-Requisites |
|
Assumptions | |
Available since version | 10.1.4.5.2 |
RunTimes | All Runtimes. |
Parameters
Parameter | Description | Possible Values | Can be Null? |
---|---|---|---|
trxDefKey | Transaction Definition fully qualified key. This is specified using list box that has list of transaction definitions | No | |
durationDescriptor | Duration Descriptor | No | |
transactionStatusGroupId | Group of Transaction Statuses that should be considered. If no group is specified then Transaction Status is ignored in the query. | Yes | |
ignoreCurrentTransactionInQuery | Flag to indicate if the current transaction has to be ignored | ||
forTheSameCurrentUserId | Flag to indicate if only transactions belonging to the current user to be counted.
If this flag is false then transactions irrespective of users will be considered. |
No | |
allowGapsForChecks | Flag to indicate if gaps are allowed while checking for conditions.
If this value is TRUE then gaps would be allowed while checking for conditions. |
No | |
noOfTransactionsToCheckFor1stCheck | Number of transactions that should satisfy the 1st check. Specify positive integers. | No | |
filter101Key
filter102Key filter103Key filter104Key filter105Key filter106Key |
Filter Keys for 1st check.
These parameters specify the left hand side of the filter conditions. It represents fully qualified key of the transaction field. This field could be an entity field or data field or transaction attribute or request attribute. Note: There is a widget for this that renders list box with all the data fields. |
Yes | |
filter101Condition
filter102Condition filter103Condition filter104Condition filter105Condition filter106Condition |
Filter Conditions for 1st check.
These parameters represent the operator and right hand side of the filter condition. It represents fully qualified key of the filter condition. Note: There is a widget for this that renders the list box of operators and a way to specify simple value or group name (in case of IN or NOT IN operator) or select another field in the transaction. |
Wherever the filterKey is specified, appropriate condition has to be specified | |
noOfTransactionsToCheckFor2ndCheck | Number of transactions that should satisfy the 2nd check. Specify positive integers. | No | |
filter201Key
filter202Key filter203Key filter204Key filter205Key filter206Key |
Filter Keys for 2nd check.
These parameters specify the left hand side of the filter conditions. It represents fully qualified key of the transaction field. This field could be an entity field or data field or transaction attribute or request attribute. Note: There is a widget for this that renders list box with all the data fields. |
||
filter201Condition
filter202Condition filter203Condition filter204Condition filter205Condition filter206Condition |
Filter Conditions for 2nd check.
These parameters represent the operator and right hand side of the filter condition. It represents fully qualified key of the filter condition. Note: There is a widget for this that renders the list box of operators and a way to specify simple value or group name (in case of IN or NOT IN operator) or select another field in the transaction. |
Wherever the filterKey is specified, appropriate condition has to be specified |
Possible User Scenarios
This condition can be used whenever you want to trigger a rule based on checks that are satisfied on consecutive transactions in a given duration.
For example, you have configured a transaction called purchase and you want to trigger a rule if the current/last transaction amount > $1000 and there were at least 3 transactions before that where the amount < $10.
So, 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.
Select the number of transactions for 1st check as "1" and select the condition to check as "Amount" "Greater Than" 1000, since you want to check only one transaction for the big amount.
Select the number of transactions for 2nd check as "3" and select the condition to check as "Amount" "Less Than" 10, since you want to check 3 transactions for smaller amounts.
If you want to allow other transactions in between the checks for 1st check and 2nd check then select "Allow Gaps in Transactions during checks?" as TRUE otherwise select FALSE.
Condition | TRANSACTION: Compare Transaction Aggregrates (Sum/Avg/Min/Max) across two different durations |
---|---|
Description | Compare transactions aggregrates across two different durations |
Pre-Requisites |
|
Assumptions | |
Available since version | 10.1.4.5.2 |
RunTimes | All Runtimes. |
Parameters
Parameter | Description | Possible Values | Can be Null? |
---|---|---|---|
trxDefKey | Transaction Definition fully qualified key. This is specified using list box that has list of transaction definitions | No | |
aggregrateFunctionEnum | Aggregrate function that has to be used | No | |
elementDefFQKey | Transaction Entity/Data Element that needs to be aggregrated | No | |
durationDescriptorFor1stDuration | Select duration for the first aggregrate | No | |
durationDescriptorFor2ndDuration | Select duration for the second aggregrate | No | |
comparisonConditionEnum | Comparison condition | No | |
multiplierFor2ndDurationValue | Multiplier value for the second aggregrate. Only non-zero and null values will be considered | Yes | |
forTheSameCurrentUserId | Boolean flag to indicate whether only transactions belonging to the current user to be counted or not | Yes | |
ignoreCurrentTransactionInQuery | Flag to indicate if the current transaction has to be ignored | No | |
specifiedConditionEnumForCount | Condition for the count check. Select only valid operators that are relevant to numeric values | No | |
specifiedValueForCount | Count value to check. Specify only valid positive integers. | No | |
applyFilterOnCurrentTransaction | Flag to indicate if the filter conditions have to validated on current transaction before doing the count | No | |
filter1Key
filter2Key filter3Key filter4Key filter5Key filter6Key |
These parameters specify the left hand side of the filter conditions. It represents fully qualified key of the transaction field.
This field could be an entity field or data field or transaction attribute or request attribute. Note: There is a widget for this that renders list box with all the data fields. |
Yes | |
filter1Condition
filter2Condition filter3Condition filter4Condition filter5Condition filter6Condition |
These parameters represent the operator and right hand side of the filter condition. It represents fully qualified key of the filter condition.
Note: There is a widget for this that renders the list box of operators and a way to specify simple value or group name (in case of IN or NOT IN operator) or select another field in the transaction. |
Wherever the filterKey is specified, appropriate condition has to be specified |
Possible User Scenarios
This condition can be used whenever you want to trigger a rule based on the comparison of aggregrates of a transaction entity/data element across two different durations.
For example, you have configured a transaction called purchase and you want to trigger if sum of transaction amount for current day is 20% more than the sum of all transactions amount of previous day for that user.
To achieve this
Select the "Amount" as the element to be aggregrated and "Sum" as the aggregrate function.
Then select 1st duration as 1 calendar day and 2nd duration as 1 calendar day before 1 day.
Then select comparison condition as 'Greater than' and multiplier value as 1.2 (100%+20%).
Condition | TRANSACTION: Compare Transaction counts across two different durations |
---|---|
Description | Compare transactions counts across two different durations |
Pre-Requisites |
|
Assumptions | |
Available since version | 10.1.4.5.2 |
RunTimes | All Runtimes. |
Parameters
Parameter | Description | Possible Values | Can be Null? |
---|---|---|---|
trxDefKey | Transaction Definition fully qualified key. This is specified using list box that has list of transaction definitions | No | |
durationDescriptorFor1stDuration | Select duration for the first count | No | |
durationDescriptorFor2ndDuration | Select duration for the second count | No | |
comparisonConditionEnum | Comparison condition | No | |
multiplierFor2ndDurationValue | Multiplier value for the second aggregrate. Only non-zero and null values will be considered | Yes | |
forTheSameCurrentUserId | Boolean flag to indicate whether only transactions belonging to the current user to be counted or not | Yes | |
ignoreCurrentTransactionInCount | Flag to indicate if the current transaction has to be ignored | No | |
specifiedConditionEnumForCount | Condition for the count check. Select only valid operators that are relevant to numeric values | No | |
specifiedValueForCount | Count value to check. Specify only valid positive integers. | No | |
applyFilterOnCurrentTransaction | Flag to indicate if the filter conditions have to validated on current transaction before doing the count | No | |
filter1Key
filter2Key filter3Key filter4Key filter5Key filter6Key |
These parameters specify the left hand side of the filter conditions. It represents fully qualified key of the transaction field.
This field could be an entity field or data field or transaction attribute or request attribute. Note: There is a widget for this that renders list box with all the data fields. |
Yes | |
filter1Condition
filter2Condition filter3Condition filter4Condition filter5Condition filter6Condition |
These parameters represent the operator and right hand side of the filter condition. It represents fully qualified key of the filter condition.
Note: There is a widget for this that renders the list box of operators and a way to specify simple value or group name (in case of IN or NOT IN operator) or select another field in the transaction. |
Wherever the filterKey is specified, appropriate condition has to be specified |
Possible User Scenarios
This condition can be used whenever you want to trigger a rule based on the comparison of transaction counts across two different durations.
For example, you have configured a transaction called purchase and you want to trigger 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,
Select 1st duration as 1 calendar day and 2nd duration as 1 calendar day before 1 day.
Then select the comparison condition as "Greater than" and multiplier value as 1.2 (100%+20%).
Condition | TRANSACTION: Compare Transaction Entity/Element counts across two different durations |
---|---|
Description | Compare transaction entity/element counts across two different durations |
Pre-Requisites |
|
Assumptions | |
Available since version | 10.1.4.5.2 |
RunTimes | All Runtimes. |
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 non-zero and null values will be considered | Yes | |
forTheSameCurrentUserId | Boolean flag to indicate whether only transactions belonging to the current user to be counted or not | Yes | |
ignoreCurrentTransactionInCount | Flag to indicate if the current transaction has to be ignored | No | |
specifiedConditionEnumForCount | Condition for the count check. Select only valid operators that are relevant to numeric values | No | |
specifiedValueForCount | Count value to check. Specify only valid positive integers. | No | |
applyFilterOnCurrentTransaction | Flag to indicate if the filter conditions have to validated on current transaction before doing the count | No | |
filter1Key
filter2Key filter3Key filter4Key filter5Key filter6Key |
These parameters specify the left hand side of the filter conditions. It represents fully qualified key of the transaction field.
This field could be an entity field or data field or transaction attribute or request attribute. Note: There is a widget for this that renders list box with all the data fields. |
Yes | |
filter1Condition
filter2Condition filter3Condition filter4Condition filter5Condition filter6Condition |
These parameters represent the operator and right hand side of the filter condition. It represents fully qualified key of the filter condition.
Note: There is a widget for this that renders the list box of operators and a way to specify simple value or group name (in case of IN or NOT IN operator) or select another field in the transaction. |
Wherever the filterKey is specified, appropriate condition has to be specified |
Possible User Scenarios
This condition can be used whenever you want to trigger a rule based on the comparison of any transaction entity/element counts across two different durations.
For example, you have configured a transaction called purchase and you 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 achieve this,
Select "Credit card" as the element to be counted and select 1st duration as 1 calendar day and 2nd duration as 1 calendar day before 1 day.
Then select the comparison condition as "Greater than" and the multiplier value as 1.2 (100%+20%).
Transaction Administration enables security policy administrators to more easily examine and evaluate transactional entities and define risk levels for transactions to proactively prevent fraud. The Transaction Administration feature was enhanced in 10.1.4.5. In 10.1.4.5.1 and 10.1.4.5.2, the transaction rule conditions were redesigned and simplified.
This section contains mapping information for users configuring their 10.1.4.3 rules using the 10.1.4.5.2 rule conditions.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Count of any entity or element of a Transaction using filter conditions
Mapping Notes:
In the rule condition select the required entity that needs to be counted and specify the count value that needs to be matched.
In the filter condition, select the "Device Id" as the left hand side, operator as 'Equals' and select the "Current" and "Device Id" from the right hand side drop down list.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Count of any entity or element of a Transaction using filter conditions
Mapping Notes:
In the rule condition select the required entity that needs to be counted and specify the count value that needs to be matched.
In the filter condition, select the "IP Address" as the left hand side, operator as 'Equals' and select the "Current" and "IP Address" from the right hand side drop down list.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Transaction Count using filter conditions
Mapping Notes:
Create a Transaction Status Group with required statuses
In the filter condition, select the "Transaction Status" as the left hand side, operator as 'IN' and select the appropriate Transaction Status Group.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Transaction Count using filter conditions
Mapping Notes:
In the filter condition, select the amount field as the left hand side, operator as 'Greater Than' or other appropriate one and select the "Value" and enter the value to be matched.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Transaction Count using filter conditions
Mapping Notes:
Use the filter conditions and configure the conditions that should be satisfied for counting the transactions.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Current Transaction using the filter conditions
Mapping Notes:
Use the filter conditions and configure the conditions involving time and entities.
Note: Time value should be specified in HH24:MI:SS format.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Transaction Count using filter conditions
Mapping Notes:
Select the duration using duration descriptor widget.
Use the filter conditions and configure the conditions that should be satisfied for counting the transactions.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Count of any entity or element of a Transaction using filter conditions
Mapping Notes:
Select the entity to be counted and the specified comparison operator and specify count to be compared.
Select the duration using duration descriptor widget.
Use the filter conditions and configure the conditions that should be satisfied for counting the transaction entity.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Current Transaction using the filter conditions
Mapping Notes:
Use the filter condition with the given transaction data element in the left hand side, appropriate operator and select "Value" from the drop down list and specify value to be compared with.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Current Transaction using the filter conditions
Mapping Notes:
Use the filter condition with the given entity and entity data element in the left hand side, "IN" operator and select "Group" from the drop down list and select appropriate Group.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Transaction Aggregrate and Count using filter conditions
Mapping Notes:
Specify the element to compare the aggregrate and specify the aggregrate value to be compared, also specify the count to be compared with.
Use filter conditions to narrow the transactions to be considered for computing the count and aggregrate.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Current Transaction using the filter conditions
Mapping Notes:
Use the filter conditions to configure the checks
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Count of any entity or element of a Transaction using filter conditions
Mapping Notes:
Select the entity/data element to be counted and the specified comparison operator and specify count to be compared.
Select the duration using duration descriptor widget.
Use the filter conditions and configure the conditions that should be satisfied for counting the transaction entity/data element.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Current Transaction using the filter conditions
Mapping Notes:
Use the filter condition and select the element to compare with on the left hand side and appropriate operator and the select element to be compared with on the right hand side.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Transaction Count using filter conditions
Mapping Notes:
Select the duration using duration descriptor widget.
Use the filter conditions and configure the condition with the elements to compare on the left hand side, operator as "Equals" and select "Current" and the element to be compared with.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Transaction Aggregrate and Count using filter conditions
Mapping Notes:
Specify the element to compare the aggregrate and specify the aggregrate value to be compared, also specify the count to be compared with.
Select the duration using duration descriptor widget.
Use filter conditions and select the element to be matched on the left hand side, select operator and then select "Current" and the relevant element from current transaction data to be compared with.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Current Transaction using the filter conditions
Mapping Notes:
Use the filter condition with operator IN to check for value in Groups/Lists.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Count of any entity or element of a Transaction using filter conditions
Mapping Notes:
Select the entity/data element to be counted and the specified comparison operator and specify count to be compared.
Select the duration using duration descriptor widget.
Use the filter conditions and configure the conditions that should be satisfied for counting the transaction entity/data element.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Count of any entity or element of a Transaction using filter conditions
Mapping Notes:
Select the entity to be counted and the specified comparison operator and specify count to be compared.
Select the duration using duration descriptor widget.
Use the filter conditions and configure the conditions that should be satisfied for counting the transaction entity
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check if consecutive Transactions in given duration satisfy the filter conditions
Mapping Notes:
Transactions will be fetched and sorted in descending order of create time of transactions.
If "Ignore current Transaction in query" parameter is false then current transaction will be the first in the list of transactions.
Select the duration using duration descriptor widget.
Enter the number of transactions that should satisfy the first check and then use the 1st check filter conditions to specify the checks.
Enter the number of transactions that should satisfy the second check and then use the 2nd check filter conditions to specify the checks.
If gaps should be allowed before the 1st check or between 1st check and 2nd check then select the "Allow Gaps in Check?" parameter as TRUE.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Current Transaction using the filter conditions
Mapping Notes:
Use the filter condition with operator IN to check for value in Groups/Lists.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Compare Transaction Entity or Element Counts across two different durations
Mapping Notes:
Select the entity/data element to be counted
Select the durations for 1st set and 2nd set of transactions using duration descriptor widgets
Specify the comparison condition and multiplier for the count value of 2nd set of transactions
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check if consecutive Transactions in given duration satisfy the filter conditions
Mapping Notes:
Select the duration using duration descriptor
Select the number of transactions to pass for the 1st check
Specify the 1st check that has to be passed using the filter conditions
If there is one more check, then specify the number of transactions for the 2nd check and use the filter conditions to specify that check
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Transaction Aggregrate and Count using filter conditions
Mapping Notes:
Specify the element to compare the aggregrate and specify the aggregrate value to be compared, also specify the count to be compared with.
Select the duration using duration descriptor widget.
Use filter conditions and select the element to be matched on the left hand side, select operator and then select "Current" and the relevant element from current transaction data to be compared with.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Transaction Aggregrate and Count using filter conditions
Mapping Notes:
Specify the element to compare the aggregrate and specify the aggregrate value to be compared, also specify the count to be compared with.
Select the duration using duration descriptor widget.
Use filter conditions and select the element to be matched on the left hand side, select operator and then select "Current" and the relevant element from current transaction data to be compared with.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Transaction Aggregrate and Count using filter conditions
Mapping Notes:
Specify the element to compare the aggregrate and specify the aggregrate value to be compared, also specify the count to be compared with.
Select the duration using duration descriptor widget.
Use filter conditions and select the element to be matched on the left hand side, select operator and then select "Current" and the relevant element from current transaction data to be compared with.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Current Transaction using the filter conditions
Mapping Notes:
Use the filter condition and select the element to compare with on the left hand side and appropriate operator and the select element to be compared with on the right hand side.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Current Transaction using the filter conditions
Mapping Notes:
Use the filter condition and select the element to compare with on the left hand side and appropriate operator and the select element to be compared with on the right hand side.
Equivalent 10.1.4.5.2 Rule Condition:
Not directly available
Mapping Notes:
It is advised to use combination of "TRANSACTION: Check Current Transaction using the filter conditions" and "Session: Check param value" to achieve this.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Current Transaction using the filter conditions
Mapping Notes:
Use the filter condition and select the element to compare with on the left hand side and appropriate operator and the select element to be compared with on the right hand side.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Transaction Count using filter conditions
Mapping Notes:
Select count to check as "1" and count compare condition as "Greater Than Equals".
Select the duration using duration descriptor widget.
Use the filter conditions and configure the condition with the elements to compare on the left hand side, operator as "Greater Than" and select "Value" and specify the numeric value in text field.
Transaction Administration enables security policy administrators to more easily examine and evaluate transactional entities and define risk levels for transactions to proactively prevent fraud. The Transaction Administration feature was enhanced in 10.1.4.5. In 10.1.4.5.1 and 10.1.4.5.2, the transaction rule conditions were redesigned and simplified.
This mapping section contains mapping information for users configuring their 10.1.4.5 rules using the 10.1.4.5.2 rule conditions.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Current Transaction using the filter conditions
Mapping Notes:
In the filter condition, select the required entity that needs to be matched as the left hand side, operator as 'Equals' and select the "Current" and the required Entity to match with from the right hand side drop down list.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Current Transaction using the filter conditions
Mapping Notes:
Use the two filter conditions with the given entity date element in the left hand side and use "greater than equals" with the first date and "less than equals" with the second date.
Date values should be in the format in "mm/dd/yyyy HH24:MI:SS"
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Current Transaction using the filter conditions
Mapping Notes:
Use the filter condition with the given entity element in the left hand side, operator as IN and the required group/list on the right hand side.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Current Transaction using the filter conditions
Mapping Notes:
Use two filter conditions with the given entity element in the left hand side and use "greater than equals" with the first value and "less than equals" with the second value.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Current Transaction using the filter conditions
Mapping Notes:
Use the filter condition with the given transaction data element in the left hand side, operator as IN and the required group/list on the right hand side.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Current Transaction using the filter conditions
Mapping Notes:
Use the two filter conditions with the given transaction date element in the left hand side and use "greater than equals" with the first date and "less than equals" with the second date.
Date values should be in the format in "mm/dd/yyyy HH24:MI:SS"
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Current Transaction using the filter conditions
Mapping Notes:
Use two filter conditions with the given transaction numeric element in the left hand side and use "greater than equals" with the first value and "less than equals" with the second value.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Transaction Count using filter conditions
Mapping Notes:
Use one filter condition with the given entity on the left hand side and use "equals" operator and select "Current" and then the required entity that needs to be matched.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Transaction Count using filter conditions
Mapping Notes:
Use one filter condition with the given entity element on the left hand side and use "equals" operator and select "Current" and then the required entity element that needs to be matched.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Transaction Count using filter conditions
Mapping Notes:
Use one filter condition with the given transaction data element on the left hand side and use "equals" operator and select "Current" and then the required transaction data element that needs to be matched.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Transaction Count using filter conditions
Mapping Notes:
Use as many filter conditions as the number of transaction data elements and in each filter condition, select the transaction data element on the left hand side and use "equals" operator and select "Current" and then the required transaction data element that needs to be matched.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Transaction Count using filter conditions
Mapping Notes:
Use one filter condition with the given entity data element on the left hand side and use "IN" operator and select the required Group/List.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Transaction Count using filter conditions
Mapping Notes:
Use one filter condition with the given entity element on the left hand side and use appropriate operator and select "Value" and then enter the value to be matched.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Transaction Count using filter conditions
Mapping Notes:
Use one filter condition with the given transaction data element on the left hand side and use "IN" operator and select the required Group/List.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Transaction Count using filter conditions
Mapping Notes:
Use one filter condition with the given transaction data element on the left hand side and use appropriate operator and select "Value" and then enter the value to be matched.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Transaction Count using filter conditions
Mapping Notes:
Use one filter condition with the "IP Address" on the left hand side and use "equals" operator and select "Current" and "IP Address" from the drop down list.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Transaction Count using filter conditions
Mapping Notes:
Use one filter condition with the "IP Address" on the left hand side and use "equals" operator and select "Value" and enter the required "IP Address" to be matched in the text field.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Transaction Count using filter conditions
Mapping Notes:
Configure filter conditions if required.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Transaction Aggregrate and Count using filter conditions
Mapping Notes:
Configure rule condition by selecting the required Transaction Data Element as the field to aggregrate. Leave the count value to be matched as NULL.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Transaction Aggregrate and Count using filter conditions
Mapping Notes:
Configure rule condition by selecting the required Transaction Entity Element as the field to aggregrate. Leave the count value to be matched as NULL.
Equivalent 10.1.4.5.2 Rule Condition:
TRANSACTION: Check Count of any entity or element of a Transaction using filter conditions
Mapping Notes:
Configure rule condition by selecting the required Entity to be counted and specify the count value to be matched along with appropriate comparison operator.
If required use filter conditions to narrow down the transactions that need to be included for counting the entity.