20 Managing Transactions

This chapter focuses on the creation and usage of transaction definitions and the mapping of client specific data into the OAAM database. The mapping will be used by administrators to more easily examine transactional entities and define risk levels for transactions and by investigators to review transactional data to proactively prevent fraud. This chapter includes these sections:

• Transaction Handling

• Overview of Creating a Transaction Definition

• Creating and Using Transaction Definitions

• Managing Transaction Definitions

• Setting Targeted Purging for Transaction Data Per Transaction Definition

• Transaction Searches

• OAAM Transaction Use Cases

20.1 Transaction Handling

Oracle Adaptive Access Manager can evaluate the risk associated with a transaction in real-time to prevent fraud and misuse. Any user activity that requires monitoring after successfully logging in can be termed as a transaction. A transaction consists of useful information that are being processed by OAAM for risk analysis and the related data can be grouped together to form entities for ease of operation. Using the Transactions feature requires native integration. Refer to Chapter 18, "Modeling the Transaction in OAAM" for details about the deployment. The flow of OAAM transaction handling is as follows:

1. An administrator using Oracle Adaptive Access Manager defines the entities and transaction data to use (transaction definition) to represent the client transactions.

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

3. The client's transaction page passes the required information to Oracle Adaptive Access Manager to monitor the activity.

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

5. Oracle Adaptive Access Manager enforces authorization rules and fraud analysis on a client's transaction data based on transaction definitions.

20.2 Overview of Creating a Transaction Definition

The following tasks are required to create a transaction definition:

1. Create the transaction definition. Figure 20-1 shows the transaction definition creation process.

   Figure 20-1 Create Transaction Definition Process

   
   

   The transaction definition captures the transaction that directly maps with the customers transaction. The transaction data from the customer is processed by OAAM for risk analysis. Figure 20-2 shows the relationship between entities and transactions and how they are used in analytics.

   Figure 20-2 Data Relationships

   
   

   The high-level steps to creating and using transaction definitions are as follows:

   1. Add entity instances to the transaction definition.

      Refer to Section 20.4.3, "Add an Existing Entity to the Transaction" or Section 20.4.4, "Add a New Entity to the Transaction" for details.

   2. Add 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 20.4.5, "Define Transaction Data for OAAM" for details.

   3. Add source data 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 20.4.6, "Source Data for the Transaction from the Client's End" for details.

   4. Map transaction to source data and map entity to source data.

      Refer to Section 20.4.7.2, "Mapping Entities to the Source Data" for details.

      Mapping connects the source data to our entities and transaction data.

   5. Activate the transaction definition.

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

2. Create an alert. The alert is used to notify administrators about anomalies or send information about the system when rules are triggered.

3. Create a policy that uses transaction conditions.

4. Add a rule to the policy. The rule must contain a transaction condition.

5. When adding the rule to the policy, select your transaction definition for the Select Transaction to check field.

6. Link the alert to the policy.

7. Verify the policy by logging into the client application and performing transactions.

20.3 Pre-requisites for Performing Analysis on Transactions

In order for Oracle Adaptive Access Manager to perform analysis on transactions, you must determine how to represent the transactions in Oracle Adaptive Access Manager, how to process the data coming in, how to use the data, and how to display the data.

Look at the available business data by logging into the application.

1. Identify all the entities and transaction fields of interest for the third-party transaction.

2. On paper, determine the transaction definition and the mapping of the source data to transaction definition. Source data elements are the fields from the customer application. Make sure the source data keys match the keys used by the customer application.

3. Log in to Oracle Adaptive Access Manager.

4. On the Sign In page, enter your credentials and click Sign In.

   Upon a successful sign in, Oracle Adaptive Access Manager displays the OAAM Admin Console.

5. Create the necessary entities and activate them. In the example, customer, credit card, shipping address, and billing address are entities that you would create. For information, refer to Chapter 19, "Creating and Managing Entities."

Now, you are ready to create an OAAM transaction. The transaction definition captures the transaction that directly maps with the customers transaction. This definition will be used in policies for monitoring.

20.4 Creating and Using Transaction Definitions

OAAM uses a transaction definitions to specify the mapping between the customer data and the system database. These mappings are created for each transaction.

20.4.1 Open the Transactions Page

The Transactions page is the starting place for managing your transaction definitions. From the Transactions page, you can:

• Open transaction definitions and transaction search pages

• View transaction definitions

• Create new transaction definitions

• Activate transaction definitions

• Deactivate transaction definitions

• Import transaction definitions

• Export transaction definitions

• Search for transaction instances and logs

• Search for entity instances and logs

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

To open the Transactions page, double-click Transactions in the Navigation tree.

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.

20.4.2 Create the Transaction Definition

To start the creation of the transaction definition, proceed as follows:

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

   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.

   A New Transaction Definition page appears.

2. In the New Transaction Definition page, enter the transaction definition name.

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

3. Enter the description.

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

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

5. After making the required entries, click the Apply button.

   A new transaction is created. You can now add a new entity or map an existing entity.

20.4.3 Add an Existing Entity to the Transaction

An entity is a data structure that can be reused in multiple transactions. For example, the Address entity could be used as a shipping address, billing address, home address, and so on. Most entities also combine multiple data points into the structure for data optimization. For example, the set of properties for an employee entity could include first name, last name, social security number, department, and salary entity properties. When associating the employee entity with a transaction you can create an instance for contractors, offshore employees, and so on.

You can add instances of entities to the transaction definition and later map the data fields to the customer source data.

In the Entity Selection page:

1. Click Add Existing Entity.

   The Add Entity screen appears.

2. Search for the entity and click the search button next to the Entity Name field.

   Inactive entities are not available for adding to transactions.

   You can single-select an entity.

3. Click the Next button.

   The preview shows the data fields associated with the selected entity and the linked entities of the selected entity.

   Figure 20-3 Adding an Existing Entity

   
   

4. Enter the instance name.

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

5. Click Add to add the selected entity.

   The entity and the linked entities are shown in the Entities tab.

Figure 20-4 Linked Entities

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

You can add multiple instances of the same entity.

20.4.4 Add a New Entity to the Transaction

In the Entity Selection page:

1. Click Create New Entity.

2. Enter Entity Name and Description and click Next.

   Refer to Section 19.2.4.1, "Initial Steps" in Chapter 19, "Creating and Managing Entities" for details.

3. In the Entity Data page, add data elements of the entity.

   Best Practice: The data type, length, and so on of the fields in the transaction definition should not be altered after the transaction has been defined and used in a transaction.

   Refer to Section 19.2.4.2, "Adding and Editing Data Elements" in Chapter 20, "Managing Transactions" for details.

4. In the Entity ID Scheme page, select the elements that you want to use to uniquely identify an entity.

   Refer to Section 19.2.4.3, "Selecting Elements for the ID Scheme" in Chapter 19, "Creating and Managing Entities" for details.

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

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

   Refer to Section 19.2.4.4, "Specifying Data for the Display Scheme" in Chapter 19, "Creating and Managing Entities" for details.

6. Perform Steps 1 through 5 to create new entities to add to the transaction definition.

20.4.5 Define Transaction Data for OAAM

Transaction data is unique or transient 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.

Examples of transaction data are as follows:

• Dollar amount

• Coupon code

• Item number

To add transaction data to the transaction definition, proceed as follows:

1. Click Data tab.

   Figure 20-5 Retail Ecommerce Data

   
   

2. In the Transaction Data page, click Add Row.

3. Enter the data name.

4. Enter the data type.

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

6. Enter a description.

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

   Encrypted values from transaction data fields cannot be decrypted outside of the OAAM application. For example, encrypted data cannot be accessed from customized rule conditions. Another example, encrypted data elements cannot be viewed in BI Publisher reports.

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

9. Click Add.

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

11. 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:

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

2. For a given row there can be a total of 13 fields.

3. For Non-Numeric fields, Column value should be 1 to 10.

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

20.4.6 Source Data for the Transaction from the Client's End

Source data (client data) is the data coming from a protected application as part of a transaction.

The source data is defined by the client. To add source data elements to the transaction definition, proceed as follows:

1. Click the Source Data tab.

   Figure 20-6 Retail Ecommerce Source Data

   
   

2. In the Source Data page, click Add Row.

3. Enter the data name.

   The data name provides a way to identify the element.

   The data name must be unique.

4. Enter the data type.

5. Enter the internal ID.

   The client supplies the internal ID.

6. Enter a description.

7. Specify whether the source data is needed.

8. Press Add.

9. Add other elements by following Steps 1 through 7.

10. After adding all the source data elements, click Next.

20.4.7 Map the Source Data

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

Figure 20-7 Retail Ecommerce Mapping

20.4.7.1 Mapping Transaction Data to the Source Data

To connect the transaction data to the source data, proceed as follows:

1. In the Transaction Data Mapping section of the Mapping page, click Add Transaction Data Mapping.

2. Select the transaction data.

   The data elements to choose from are the ones you defined in the "Define Transaction Data for OAAM" section.

3. Select the Source Data.

   The client data elements to choose from are the ones that you added in the "Source Data for the Transaction from the Client's End" section.

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

5. If you selected Concatenate as the mapping type, you will have to enter separators.

6. 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). The string index begins with 0. For example if you want "acc" for "account," you would specify 0,2. By default, oaam.transaction.mapping.startindex.min is set to 0.

   Translation Params are the parameters defined when selecting certain Mapping type such as end string, lowerstring, and substring.

7. Select Map Data.

8. Map other elements by following Steps 2 through 6.

9. Click Finish or perform mapping for entities.

20.4.7.2 Mapping Entities to the Source Data

To add the mapping for the Entity elements, proceed as follows:

1. In the entities data mapping panel of the Mappings page, select the entity name.

   After you selected the entity name you are interested in mapping, the data elements of that corresponding entity will be listed in the Entity Data list.

   Figure 20-8 Mapping Entity Data

   
   

2. Select the entity data.

3. Select Source Data.

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

5. If you selected Concatenate as the mapping type, you will have to enter separators.

6. 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). The string index begins with 0. For example if you want "acc" for "account," you would specify 0,2. By default, oaam.transaction.mapping.startindex.min is set to 0.

   Translation Params are the parameters defined when selecting certain Mapping type such as end string, lowerstring, and substring.

7. Click Map Data.

8. Click Finish or perform mapping for transaction data.

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

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

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

20.4.9 Model a Policy

Determine the OAAM checkpoint that can be used to trigger the fraud policies that can perform fraud checks on the transaction. If an existing checkpoint can be reused, there is no need to create a checkpoint. Otherwise, create an OAAM checkpoint for the transaction.

Now, look at the requirements for what kind of rules should go into the fraud policy for this transaction.

Look at the list of transaction rule conditions to see which rule condition is needed. Go through the "Example Usage" section of those rule conditions.

Create an OAAM policy and add the rule.

20.4.10 Configure Trigger Results

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.

20.4.11 Integrate the Client Application

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 (The unique identifier created when the customer submitted the transaction).

• 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 transaction and verify the end-to-end flow.

20.5 Managing Transaction Definitions

Procedures to manage transaction definitions are provided in this section.

20.5.1 Searching for a Transaction Definition

In 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, proceed as follows:

1. Open the Transactions Search page, as described in Section 20.5.1, "Searching for a Transaction Definition."

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

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

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

   Table 20-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.

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

20.5.3 Editing a Transaction Definition

To edit the details of a specific transaction definition, proceed as follows:

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

1. If you are not in the Transaction Definition Details page of the transaction definition you want to edit, follow the instructions in Searching for a Transaction Definition.

2. In the General tab, to edit the transaction definition name and description.

3. In the Entity tab, select the entity you want, click Edit Entity, and edit the entity.

4. In the Data tab, edit the data elements.

5. In the Source Data tab, perform edits.

6. In the Mapping tab's Data Mapping section, click Edit Mapping, and edit the source data and mapping type and click Map.

7. In the Mapping tab's Entity Mapping section, click Edit Mapping, and edit the entity name, transaction data, source data, and mapping type fields.

8. Click Apply or Revert.

   If you click Apply, transaction definition updates are applied.

   If you click Revert, transaction definition updates are not applied

20.5.4 Deleting Transaction Definitions

To delete transaction definitions, proceed as follows:

1. Search for the transaction definition you are interested in, as described in Section 20.5.1, "Searching for a Transaction Definition."

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

   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.

   Note:

   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.

3. In the Information dialog, click OK.

   The transaction definition is deleted.

20.5.5 Exporting Transaction Definitions

To export transaction definitions, proceed as follows:

1. Open the Transaction Definitions Search page, as described in Section 20.4.1, "Open the Transactions Page."

2. In the Transaction Definitions Search page, enter the search criteria you want and click Search. Refer to Section 20.5.1, "Searching for a Transaction Definition."

3. Select all the rows corresponding to the transaction definitions you want to export.

4. Click the Export button or select Export Transaction Definition or Generate Delete Script from the Actions menu.

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

6. Save the file to disk.

   The file is exported.

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

20.5.6 Importing Transaction Definition

To import a transaction definition, proceed as follows:

1. Open the Transaction Definitions Search page, as described in Section 20.4.1, "Open the Transactions Page."

2. In the Transaction Definitions Search page, click Import or select Import Transaction Definition from the Actions menu.

3. In the Transaction Definition Import screen, click Browse and locate the transaction definitions you want to import.

4. Click OK.

20.5.7 Activating a Transaction Definition

To activate a transaction definition, proceed as follows:

1. Open the Transaction Definitions Search page, as described in Section 20.4.1, "Open the Transactions Page."

2. In the Transaction Definitions Search page, enter the search criteria you want and click Search. Refer to Section 20.5.1, "Searching for a Transaction Definition."

3. Select the row corresponding to the transaction definition you want to activate.

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

20.5.8 Deactivating a Transaction Definition

To deactivate a transaction definition, proceed as follows:

1. Open the Transaction Definitions Search page, as described in Section 20.4.1, "Open the Transactions Page."

2. In the Transaction Definitions Search page, enter the search criteria you want and click Search. Refer to Section 20.5.1, "Searching for a Transaction Definition."

3. Select the row corresponding to the transaction definition you want to deactivate.

4. Press the Deactivate button or select Deactivate from the Actions menu.

The Deactivate button is disabled if multiple rows are selected.

20.6 Setting Targeted Purging for Transaction Data Per Transaction Definition

The volume of data growth varies between transaction. For better data growth management, you can specify targeted purging of transaction data.

The targeted purging policy determines which portion of the data is purged from the database. You can decide not to purge the data at all or to purge at a different time sequence from other transactions. To set up targeted purging, proceed as follows:

1. Set up the archive tables and the flag to true, if you want the entity and transaction data to be archived.

   Note:

   You cannot selectively choose to only archive the data since archiving is part of the purge process.

2. In the Transaction Definition Details page, click the Purge tab to set the values to determine when the transaction data should be purged from the database.

   Figure 20-9 Retail Ecommerce Purge

   
   

3. If you want to purge data, deselect the option, Do not purge any transaction data. If you do not want to purge data, select Do not purge any transaction data.

   Note: Entity definition and transaction definitions are retained even though the data is being purged.

   The purging mechanism is hierarchical. Data is purged from transaction down to entity and then related entities.

4. The Purge all transaction data that has not been updated over the past option determines what data will be deleted. Set the database to delete data older than a specified number of days.

   Note:

   If the data you want to purge is in years and months, you must convert years and months into days.

   Data that has not been updated in the last 180 days is purged by default.

   If the retention period is 0, then the data is never purged. The retention period cannot take alphabetic characters or negative numbers.

20.7 Transaction Searches

This section describes the transaction search features in Oracle Adaptive Access Manager. Subsequent sections provide the Transaction Search in greater detail.

The Transaction search enables you to search for different transactions created in the system. From the transaction, you can see what kind of information will be used in authorization and analysis. For example, you can search on "Internet Banking" with search filters for Transaction Amount, Transaction Account number, and so on.

An example of a Transaction search is provided below using "Internet Banking" and its transaction-related filters.

Internet Banking:

• Transaction Amount

• Transaction Account number

• Customer.firstname

• Customer.lastname

20.8 OAAM Transaction Use Cases

This section describes example use cases for using transaction definitions.

20.8.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:

1. Identify the source data fields that make up the Money Transfer transaction.

2. Give a unique identifier that identifies the transaction type of Money Transfer.

3. Determine how to model the Money Transfer transaction in OAAM in terms of OAAM entities and transactions.

4. Identify the mapping between the source data of Money Transfer and OAAM entities and transaction.

5. Use OAAM Admin to create and activate the entities and transaction definitions for Money Transfer based on the model you came up with.

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

7. Now, look at the requirements for what kind of rules should go into the fraud policy for this transaction.

8. Based on the use case, you would want to enforce a threshold on the total in money transfer allowed per day.

9. Look at the list of transaction rule conditions in Section B.8, "Transactions Conditions." Go through the "Example Usage" section of those rule conditions.

10. For this use case, the rule condition "Transaction: Check Transaction Aggregrate and Count Using Filter Conditions" can be used to check to see whether the user has reached the threshold of $500 in money transfer per day.

11. 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 20-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.

    
    

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

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

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

15. Once the integration with client application is done, you can perform a sample money transfer transaction and verify the end-to-end flow.

20.8.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 20-3 shows the important parameters of the rule condition.

Table 20-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

20.8.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 20-4 shows the important parameters of this rule condition.

Table 20-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

20.8.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 20-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

20.8.5 Use Case: Transaction Pattern

Example: Configure a rule to determine 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 20-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