21 Managing Transactions

This chapter focuses on the creation of transaction definitions. Information on other procedures will also be provided.

21.1 Introduction and Concepts

This section introduces you to the concept of transaction definitions and how they are used in Oracle Adaptive Access Manager.

21.1.1 Transactions

A transaction is any process a user performs after successfully logging in. Examples of transactions are bill pay, money transfer, stock trade, address change, and others.

With each type of transaction, different types of details are involved.

For example, in an online transaction, the data involved may be credit cards, e-checks, debit cards, dollar amounts, name, shipping and billing addresses, and so on.

Oracle Adaptive Access Manager can evaluate the risk associated with a transaction in real-time to prevent fraud and misuse.

An Oracle Adaptive Access Manager transaction defines the structure that application data should be mapped to that will enable effective analytics.

The core elements of an Oracle Adaptive Access Manager transaction are:

entities
transaction data

When defining a transaction entities and/or transaction data must be defined.

21.1.2 Entities

An Entity is a user-defined structure, which comprises of a set of related fields grouped together, that can be re-used across different transactions. An entity is used to model a real object. For example, an "employee" entity will have a name, height, social security attributes. From the employee entity you could create an instance for contractors, offshore employees, and so on.

Figure 21-1 shows an example of the employee entity.

Figure 21-1 Entity Example

21.1.3 Transaction Data

Transaction data is unique for each transaction occurrence and therefore not reusable across different transactions. For example, the total dollar amount of a transaction would not be reused in multiple transactions so it should be transaction data and not an entity.

21.1.4 Transaction Handling

You determine the entities and transaction data to use to represent the transactions so that the Oracle Adaptive Access Manager server can process the information from the client application.

21.2 Overview of Defining and Using Transaction Definition

In transaction handling, an administrator using Oracle Adaptive Access Manager defines the entities and transaction data to use (transaction definition) to represent the client transactions.

The entities and transaction data elements are then mapped to the source data (client-specific data) so that the Oracle Adaptive Access Manager server can process the information from the client application

To set up transaction definitions:

Identify all the entities and transaction elements for the third-party transaction.

(Determine the fields of interest in the third-party online transaction page.)

For example, typical fields of interest can be the following:
- Address
- Account
- Credit Card
- Customer
- Product Details
Create entities for objects in the real world and activate them.

For example, a home address entity can have StreetNumber, StreetName, AptNumber, City, State, and ZIP.

For details for creating entities refer to Chapter 20, "Creating and Managing Entities."
Create a transaction definition. The transaction definition captures the transaction that directly maps with the customers transaction. This definition will be used in policies for monitoring.

Figure 21-2 Entities and Transaction Data Association with Source Data
Add the entities to the transaction definition.

Refer to Section 21.8, "Adding an Existing Entity to the Transaction" or Section 21.9, "Creating a New Entity and Adding It to the Transaction" for details.
Define transaction data elements for the transaction at the Oracle Adaptive Access Manager End.

For example, Transaction Amount and Transaction Date.

All data fields that do not fit into entities should be added as transaction data elements.

Refer to Section 21.10, "Defining Transaction Data for the Transaction at the Oracle Adaptive Access Manager End" for details.
Define the parameters (source data elements) for the transaction from the client's end.

Source data elements are a list of parameters from the client's end. Details from the external application fill in these fields. Make sure the source data internal IDs match to the keys used by the external application while sending the transaction data.

Refer to Section 21.11, "Defining Parameters for the Transaction from the Client's End" for details.
Map source data to transaction data and entities.

Refer to Section 21.12.2, "Mapping Entities to the Source Data" for details.
Activate the transaction definition.

Refer to Section 21.17, "Activating a Transaction Definition" for details.

Figure 21-3 Source Mapping to Transaction Data and Entities
Create an alert. The alert is used to notify administrators about anomalies or send information about the system when rules are triggered.
Create a policy that uses transaction conditions.
Add a rule to the policy. The rule must contain a transaction condition.
When adding the rule to the policy, select your transaction definition for the Select Transaction to check field.
Link the alert to the policy.
Verify the policy by logging into the client application and performing transactions.

21.3 Navigating to the Transactions Search Page

The Transaction Search page is the starting place for managing your transaction definitions.

To open the Transactions Search page, click Transactions in the Navigation tree.

You could also open the Transactions Search page by right-clicking Transactions.

Alternatively, you can:

Right-click Transactions in the Navigation tree and select List Transactions from the context menu.
Select Transactions in the Navigation tree and then choose List Transactions from the Actions menu.
Click the List Transactions button in the Navigation tree toolbar.

From the Transactions Search page, you can:

Search for transaction definitions
View transaction definitions
Create new transaction definitions
Activate transaction definitions
Deactivate transaction definitions
Import transaction definitions
Export transaction definitions

The bulk action cannot be selected for creating new, activating, and deactivating transaction definitions.

21.4 Searching for a Transaction Definition

On the Transactions Search page you can view a list of all transaction definitions and search for a transaction definition based on various criteria. The Transactions Search page provides access to the Transaction Details page for any transaction.

To search for a transaction definition:

Navigate to the Transactions Search page, as described in Section 21.4, "Searching for a Transaction Definition."

Specify criteria in the Search Filter to locate the transaction and click Search.

The search filter criteria are described in Table 21-1, "Search Filter Criteria".

If you want to reset the search parameters to the default setting, use the Reset button.

Table 21-1 Search Filter Criteria

Field	Description
Name	The name of the transaction
Key	This Key value that is used to map the client/external transaction data to transactions in the Oracle Adaptive Access Manager server.
Keyword	The keyword. The keyword filter may increase the likelihood of meaningful search results.
Status	The status of the transaction

The Search Results table displays a summary of the transactions that match these criteria specified.

By default, transactions are sorted on Name, but you can sort transactions on Key, and Keyword.

Each transaction has a name. If the description is too long to be fully shown, you can place the mouse over the text to see the entire description.

21.5 Viewing Transaction Definitions

The Search Results table displays a summary of the transactions that match the search criteria.

Click the row for the transaction you are interested in to view more details.

21.6 Prerequisites for Using Transactions

The prerequisites for using Transactions is as follows:

Using the Transactions feature involves native integration. The client's transaction page is used to pass the required information to Oracle Adaptive Access Manager to monitor the activity.
Transaction data is saved into the Oracle Adaptive Access Manager Server using the APIs described in the Oracle Fusion Middleware Developer's Guide for Oracle Adaptive Access Manager.
Only appropriate and related fields should be grouped into an entity.

21.7 Creating the Transaction Definition

To start the creation of the transaction definition:

In the Transactions Search page, click the New Transaction button.

A New Transaction Definition screen appears.

Alternatively, you can:
- Right-click Transactions in the Navigation tree and select New Transaction from the context menu.
- Select Transactions in the Navigation tree and then choose New Transaction from the Actions menu.
- Click the Create new Transaction button in the Navigation tree toolbar.
- Select the Create New Transaction button from the Search Results toolbar.
- Select New Transaction from the Actions menu in Search Results.
In the New Transaction Definition screen, enter the transaction definition name.

Enter a valid name for the name. It must be unique. Transaction definition names are not case-sensitive.
Enter the description.

Enter a description of the transaction definition to be used for informational purposes only.
Enter the definition key.

This definition key value is used to map the client/external transaction data to transaction definitions in Oracle Adaptive Access Manager.

This value is sent while making the API call for creating or updating the transaction data in OAAM Server.
After making the required entries, click the Apply button.

21.8 Adding an Existing Entity to the Transaction

In the Entity Selection page:

Click Add Existing Entity.

The Add Entity screen appears.
Search for the entity and click Next.

Inactive entities are not available for adding to transactions.

You can single-select an entity.
Enter the instance name.

The instance name must be unique. You can edit the instance name at a later date if needed.
Click Add.

The Edit Entity screen appears.
In the Edit Entity screen, you can change the instance name and display order. Then click Save.
Perform Steps 1 through 5 to add additional existing entities.

You can add multiple instances of the same entity.

The display order is autogenerated and takes the next available order. You can change the order if needed later on.

21.9 Creating a New Entity and Adding It to the Transaction

In the Entity Selection page:

Click Create New Entity.
Enter Entity Name and Description and click Next.

Refer to Section 20.4.1, "Initial Steps" in Chapter 20, "Creating and Managing Entities" for details.
In the Entity Data page, add data elements of the entity.

Refer to Section 20.4.2, "Adding and Editing Data Elements" in Chapter 21, "Managing Transactions" for details.
In the Entity ID Scheme page, select the elements that you want to use to uniquely identify an entity.

Refer to Section 20.4.3, "Selecting Elements for the ID Scheme" in Chapter 20, "Creating and Managing Entities" for details.
In the Entity Display page, specify the data elements to present and their order when you display the value of the entity and click Finish.

When the entity is saved, you are taken back to the transaction data screen.

You can cancel entity creation by using the Cancel button. The Entity Selection screen will appear when you press Cancel.

Refer to Section 20.4.4, "Specifying Data for the Display Scheme" in Chapter 20, "Creating and Managing Entities" for details.
Perform Steps 1 through 5 to create new entities to add to the transaction definition.

21.10 Defining Transaction Data for the Transaction at the Oracle Adaptive Access Manager End

To add transaction data to the transaction definition, follow these steps.

In the Transaction Data page, click Add Row.
Enter the data name.
Enter the data type.
Enter the internal ID.

The internal ID is used to identify the data element. The internal ID specified in the transaction data will be for internal use. It is typically used in rule conditions and other purposes. Do not change this internal ID after it is defined.
Enter a description.
Specify whether the element should be encrypted.

If encrypted is set to true, data is encrypted before it is stored in the database. This feature protects sensitive data.

Encrypted fields have the following constraints:
- These fields cannot be used in rules.
- These fields cannot be used in the search criteria while querying for transactions through the query screen
Specify whether the element is required.

Some data elements are not populated all the time as the data might not be available. Those elements are marked as "not required." For example "Address Line 2" in an address is not required since many addresses will not have "Address Line2."
Click Add.
Add other elements by following Steps 2 through 8.

You must fill in the required fields for the previous row before you add new transaction data to the transaction definition.
Press the Next button to add source data.

Row and Column Values

Row and column values are automatically assigned by the Oracle Adaptive Access Manager Server. If there is a need to change the Row and Column values, follow these guidelines:

Set the column values for the most commonly used fields to 1-3 or 11-13 based on whether it is non-numeric or numeric.
For a given row there can be a total of 13 fields.
For Non-Numeric fields, Column value should be 1 to 10.
For Numeric fields, Column value should be 11 to 13.

Fields in the Data tab are mapped to DATAX (for non-numeric), NUM_DATAX (for numeric) columns in VT_TRX_DATA table in database.

Fields in Entities are mapped to DATAX (for non-numeric), NUM_DATAX (for numeric) columns in VT_ENTITY_ONE_PROFILE table in database.

21.11 Defining Parameters for the Transaction from the Client's End

The source data is defined by the client. To add source data elements to the transaction definition, follow these steps:

In the Source Data page, click Add Row.
Enter the data name.

The data name provides a way to identify the element.

The data name must be unique.
Enter the data type.
Enter the internal ID.

The client supplies the internal ID.
Enter a description.
Specify whether the source data is needed.
Press Add.
Add other elements by following Steps 1 through 7.
After adding all the source data elements, click Next.

21.12 Mapping the Source Data

Mapping is a way to connect the source data to transaction data and to entities.

21.12.1 Mapping Transaction Data to the Source Data

To connect the transaction data to the source data:

In the Data Mapping section of the Mapping page, click Map Data.
Select the transaction data.

The data elements to choose from are the ones you defined in the "Defining Transaction Data for the Transaction at the Oracle Adaptive Access Manager End" section.
Select the Source Data.

The client data elements to choose from are the ones that you added in the "Defining Parameters for the Transaction from the Client's End" section.
Select the mapping type.

Select Direct, Concatenate, Endstring, and Substring.
- Select Direct if you want a one-to-one mapping of the source data element to the destination data element.
- Select Concatenate if you want to join two or more source data elements to form one data element.
- Select Endstring if you want to have last "x" number of characters from source data as the data.
- Select Substring if you want to have a part of the source data as the data.
If you selected Concatenate as the mapping type, you will have to enter separators.
If you selected Endstring, you will have to enter the last "x" number of characters.

If you selected Substring, you will have to enter the Start Index and the End Index (CSV format). For example if you want "acc" for "account," you would specify 1,3.

Translation Params are the parameters defined when selecting certain Mapping type such as endstring, lowerstring, and substring.
Select Map.
Map other elements by following Steps 2 through 6.
Click Finish or perform mapping for entities.

21.12.2 Mapping Entities to the Source Data

To add the mapping for the Entity elements, follow these steps:

In the Entities Mapping section of the Mapping page, click Map Entity.
Select the entity.
Select Source Data.
Select the mapping type.

Select Direct, Concatenate, Endstring, and Substring.
- Select Direct if you want a one-to-one mapping of the source data element to the destination data element.
- Select Concatenate if you want to join two or more source data elements to form one data element.
- Select Endstring if you want to have last "x" number of characters from source data as the data.
- Select Substring if you want to have a part of the source data as the data.
If you selected Concatenate as the mapping type, you will have to enter separators.
If you selected Endstring, you will have to enter the last "x" number of characters.

If you selected Substring, you will have to enter the Start Index and the End Index (CSV format). For example if you want "acc" for "account," you would specify 1,3.

Translation Params are the parameters defined when selecting certain Mapping type such as endstring, lowerstring, and substring.
Click Map.
Click Finish or perform mapping for transaction data.

When the transaction definition is created, the new Transaction Details page opens.

21.12.3 Editing Mapping

For transaction data, you can specify the transaction data, source data, and mapping type.

For entity mapping, you can specify the entity name, transaction data, source data, and mapping type.

21.13 Activating the Tr ansaction Definition

By default, a transaction definition is disabled on create.

Activate the transaction definition using the Activate button in the Transaction Details page.

Some steps are required before a transaction definition can be activated; otherwise, an error message will appear.

The following are required before you can activate a transaction definition:

Source/Input data elements
Mapping for all required Transaction Data Elements
Mapping for all required elements in the Transaction Entities

21.14 Editing a Transaction Definition

To edit the details of a specific transaction definition, follow these instructions:

When modifying transaction definitions, do not change the Definition ID. The Definition ID may be referenced by other applications.

If you are not on the Transaction Definition Details page of the transaction definition you want to edit, follow the instructions in Searching for a Transaction Definition.
In the General tab, to edit the transaction definition name and description.
In the Entity tab, select the entity you want, click Edit Entity, and edit the entity.
In the Data tab, edit the data elements.
In the Source Data tab, perform edits.
In the Mapping tab's Data Mapping section, click Edit Mapping, and edit the source data and mapping type and click Map.
In the Mapping tab's Entity Mapping section, click Edit Mapping, and edit the entity name, transaction data, source data, and mapping type fields.
Click Apply or Revert.

If you click Apply, transaction definition updates are applied.

If you click Revert, transaction definition updates are not applied

21.15 Exporting Transaction Definitions

To export transaction definitions:

Navigate to the Transaction Definitions Search page, as described in Section 21.3, "Navigating to the Transactions Search Page."
In the Transaction Definitions Search page, enter the search criteria you want and click Search. Refer to Section 21.4, "Searching for a Transaction Definition."
Select all the rows corresponding to the transaction definitions you want to export.
Click the Export button or select Export Transaction Definition or Generate Delete Script from the Actions menu.
In the Export Transaction Definition screen, click Export.

Generate Delete Script exports a delete script for the transaction definitions that you have selected. You can import this script later to delete the transaction definitions in the application if they are present.
Save the file to disk.

The file is exported.
Click OK

If the transaction definition selected for export and deletion is not used or does not contain transaction data from the past, a confirmation dialog is shown asking for a confirmation. If you answer "yes", the transaction definition is deleted.

When multiple transaction definitions are selected for export and deletion and if some of the transaction definitions are used or contain transaction data from the past, a message appears, telling you which ones can be deleted and which ones cannot be deleted. Links to a usage tree are available for each of the used transaction definitions. In the dialog, you are also given the option to delete the ones that are not in use or contain transaction data from the past.

21.16 Importing Transaction Definition

To import a transaction definition:

Navigate to the Transaction Definitions Search page, as described in Section 21.3, "Navigating to the Transactions Search Page."
In the Transaction Definitions Search page, click Import or select Import Transaction Definition from the Actions menu.
In the Transaction Definition Import screen, click Browse and locate the transaction definitions you want to import.
Click OK.

21.17 Activating a Transaction Definition

To activate a transaction definition:

Navigate to the Transaction Definitions Search page, as described in Section 21.3, "Navigating to the Transactions Search Page."
In the Transaction Definitions Search page, enter the search criteria you want and click Search. Refer to Section 21.4, "Searching for a Transaction Definition."
Select the row corresponding to the transaction definition you want to activate.
Press the Activate button or select Activate from the Actions menu.

The Activate button is disabled if multiple rows are selected.

All the required information must be entered (in all tabs), before you can activate the transaction. At least one source data element should be present.

21.18 Deactivating a Transaction Definition

To deactivate a transaction definition:

Navigate to the Transaction Definitions Search page, as described in Section 21.3, "Navigating to the Transactions Search Page."
In the Transaction Definitions Search page, enter the search criteria you want and click Search. Refer to Section 21.4, "Searching for a Transaction Definition."
Select the row corresponding to the transaction definition you want to deactivate.
Press the Deactivate button or select Deactivate from the Actions menu.

The Deactivate button is disabled if multiple rows are selected.

21.19 Deleting Transaction Definitions

To delete transaction definitions:

Search for the transaction definition you are interested in, as described in Section 21.4, "Searching for a Transaction Definition."
Select the row corresponding to the policies you want to delete and press the Delete button or select Delete Transaction Definition from the Actions menu.

A warning message reminds you that the changes will be permanent and asks if you want to continue.

If the transaction definitions selected for deletion are not actively used or contain transaction data from the past, a confirmation message is shown asking for confirmation. If you answer "yes", those transaction definitions are deleted.
In the Information dialog, click OK.

If you have a transaction definition and it has transaction data from the past or is being used, you are not allowed to delete the definition.

When multiple transaction definitions are selected for deletion and if some of the transaction definitions are used or contain transaction data from the past, a warning message appears, stating: "The following instances are used and cannot be deleted. Do you want to delete the other transaction definitions?" If you answer "yes", the unused transaction definitions are deleted.

21.20 Use Cases

This section describes example use cases for using transaction definitions.

21.20.1 Implementing a Transaction Use Case

Joe is a retail banking customer. Retail banking customers can make money transfers totaling up to $500 per day.

Implementation Tasks:

Identify the source data fields that make up the Money Transfer transaction.
Give a unique identifier that identifies the transaction type of Money Transfer.
Determine how to model the Money Transfer transaction in OAAM in terms of OAAM entities and transactions.

Refer to Section 21.1, "Introduction and Concepts" to find out what can be modeled as a transaction and an entity.
Identify the mapping between the source data of Money Transfer and OAAM entities and transaction.
Use OAAM Admin to create and activate the entities and transaction definitions for Money Transfer based on the model you came up with.
Determine the OAAM checkpoint that can be used to trigger the fraud policies that can perform fraud checks on the Money Transfer transaction. If an existing checkpoint can be reused, there is no need to create a checkpoint. Otherwise, create an OAAM checkpoint for the Money Transfer transaction.
Now, look at the requirements for what kind of rules should go into the fraud policy for this transaction.
Based on the use case, you would want to enforce a threshold on the total in money transfer allowed per day.
Look at the list of transaction rule conditions in Section C.2.6, "Transactions Conditions." Go through the "Possible User Scenarios" section of those rule conditions.
For this use case, the rule condition "Transaction: Check Transaction Aggregrate and Count Using Filter Conditions" can be used to check if the user has reached the threshold of $500 in money transfer per day.

Create an OAAM policy and add the rule using the "Transaction: Check Transaction Aggregrate and Count Using Filter Conditions" rule condition and specify the following in the rule condition:

Table 21-2 Transaction Rule Configuration

Parameters	Values
Transaction to check	Choose the transaction definition of Money Transfer
Aggregrate Function	Sum
Entity or Element to count	Select the data field that indicates the "money transfer amount"
Condition for Aggregrate	Select "Greater Than Equals"
Check value for Aggregrate	500
Condition for Count	Greater than Equals
Check Value for Count	1 (since you want at least 1 transaction to be there)
Duration	1 rolling day (if last 24 hours to be treated as a day) or 1 Calendar day (if the current calendar day i.e. 12am to 11.59 pm has to be considered)
Transaction Status	Select if only transactions in a particular status have to be considered
Ignore Current Transaction in Count	Select TRUE if current transaction should be excluded. If it is has to be included select FALSE and make sure the transaction data is created before running the rules.
For the same User?	Default is TRUE which makes sense since you want to consider only the transactions of current user
Apply filter checks on Current Transaction	Select TRUE if there are any conditions in Query Filter and you want to apply them to current transaction first
Query Filter	Select any filters so that you can fine tune what transactions have to be chosen to compute the aggregate before it checks if the threshold is reached.

Once the rule condition is configured, specify what should be the Results if the rule condition is satisfied. You can configure Alert and Action groups that indicate that the user has reached his threshold and also a score. The client application can interpret the result and take appropriate action in terms of redirecting the user to the relevant pages that indicate that the user action is not allowed.
Now, you have the setup ready in OAAM so that the transaction can be created in OAAM and fraud policies and rules can be triggered.
Integrate the client application with OAAM using OAAM shared libraries. Refer to "Integrating Native Java Applications" in the Oracle Fusion Middleware Developer's Guide for Oracle Adaptive Access Manager for details of the integration. This is required since transactions functionality is available through native integration. As part of this integration, the client application does two things:
- Call the OAAM Data Collection API to pass the transaction data. OAAM Data Collection APIs persist the transaction data based on the transaction definition into the OAAM database. This results in the creation of OAAM entities and transaction data. The output of these APIs is a Transaction ID.
- Call the OAAM Rules API to trigger the fraud policies/rules associated to the checkpoint. This step results in triggering the rules engine that would execute the policies and rules associated to this checkpoint and creating Alerts if the associated rules trigger. The output of these APIs is a set of actions and risk score as returned by the policies and rules.
Once the integration with client application is done, you can perform a sample money transfer transaction and verify the end-to-end flow.

21.20.2 Use Case: Transaction Frequency Checks

These kinds of checks can be implemented using the "Transaction: Check Transaction Count Using Filter Condition" rule condition. Table 21-3 shows the important parameters of the rule condition.

Table 21-3 Transaction Frequency Checks

Parameters	Values
Select Transaction to count	Select the transaction definition for which this check has to be applied
Specified Condition For Count	Select "Greater Than Equals"
Specified Check Value for Count	Enter the frequency value
Duration	Enter the duration

21.20.3 Use Case: Transaction Frequency and Amount Check against Suspicious Beneficiary Accounts

This kind of check can be implemented using the "Transaction: Check Transaction Aggregrate and Count Using Filter Conditions" rule condition. Table 21-4 shows the important parameters of this rule condition.

Table 21-4 Transaction Frequency and Amount Check against Suspicious Beneficiary Accounts

Parameters	Values
Select Transaction to check	Select the transaction definition for which this check has to be applied
Select Aggregrate Function	Sum
Select Entity or Element to count	Select the numeric data field that indicates the "amount"
Select Condition for Aggregrate	Select "Greater Than Equals"
Specified Check value for Aggregrate	Enter the value of amount to check
Specified Condition for Count	Greater than Equals
"Specified Check Value for Count	Enter frequency value
Duration	Enter the duration

21.20.4 Use Case: Transaction Check against Blacklisted Deposit and Beneficiary Accounts

This kind of check can be implemented using the "Transaction: Check Current Transaction Using Filter Condition" rule condition.

Before configuring the rule, create the two groups of accounts, one that has the list of blacklisted deposit accounts and the other that has the list of blacklisted beneficiary accounts. Those groups should be populated with the lists of accounts that are blacklisted. These tasks can be done using OAAM Admin.

After that, create the rule using the "Transaction: Check Current Transaction Using Filter Condition" rule condition and configure it as follows:

Table 21-5 Transaction Check against Blacklisted Deposit and Beneficiary Accounts

Parameters	Values
Select Transaction to check	Select the transaction definition for which this check has to be applied
Filter condition	Select Deposit Account Data Field from the Transaction and specify the condition as "IN" and then select the group as the Blacklisted Deposit Accounts
Filter condition	Select Beneficiary Account Data Field from the Transaction and specify the condition as "IN" and then select the group as the Blacklisted Beneficiary Accounts

21.20.5 Use Case: Transaction Pattern

Example: Configure a rule to find out whether several small transactions (where amount < $10) has happened before a big transaction (amount > $500) is attempted in the last couple of hours. If yes, then the user should be challenged before this huge transaction.

To configure this kind of check the rule condition "Transaction: Check if consecutive Transactions in given duration satisfy the filter conditions" can be used.

The rule condition parameters have to be configured as follows:

Table 21-6 Transaction Pattern

Parameters	Values
Select Transaction to check	Select the transaction definition for which this check has to be applied
Duration	Enter the duration of transactions that has to be considered
Allow gaps in transactions during checks?	If gaps are allowed then select TRUE, otherwise select FALSE
No of transactions to check for 1st set of conditions	Enter number of transactions that should match the first set of conditions. For example, if you want to first check 2 small transactions then enter the value as "2".
Checks for 1st set of conditions	Enter the following conditions that should match the first set of transactions Select Amount data element with condition as "Less Than" and value as 10.
No of transactions to check for 2nd set of conditions	Enter number of transactions that should match the first set of conditions. For example, if you want to check 1 big transaction after 2 small transactions then enter the value for "No of transactions to check for 2nd set of conditions" as "1".
Checks for 2nd set of conditions	Enter the following condition that should match the next set of transactions. Select Amount data element with condition as "Greater Than" and value as 500

21.20.6 Use Case: Composite or Nested Transactions

A composite transaction is when a master transaction is defined, and then a child transaction is defined, and the child transaction is associated with the parent.

Composite or Nested Transactions can be implemented in OAAM by performing the following tasks:

Identify the master/parent transaction and the detail/child transaction.
Identify the data element that uniquely identifies the master/parent transaction; add that data element as one of the transaction data elements to the detail/child transaction definition.
Configure two different checkpoints. One checkpoint for evaluating fraud policies on master/parent transaction and the other for evaluating fraud policies on detail/child transactions.
Make sure the client application makes separate OAAM Data Collection API calls to persist the transactions of master/parent transaction the detail/child transactions.
Policies related to detail/child transactions can be evaluated first to see if there are suspicious child transactions. To consider other child transactions that are part of the same parent transaction, the parent transaction identifier can be used since that is the common data element that ties all the child transactions together.

Currently there are no specific rule conditions that act on composite transactions.