A.23 Advanced Feature for ASC Use Case

This section explains about ASC Use case Advanced features.

Fine Grain Data Access Control for Workspace

Institutions often need to restrict data access to users based on jurisdiction to comply with data residency or other privacy regulations. This functionality can be used to ensure that users will be able to access data only from those jurisdictions they are entitled to.

Prerequisites

• Assuming existing / new Users are created using AAI or third-party IDCS.
• Security mapping between users to jurisdictions is done using AML BD application UI.
• User Mapped Jurisdiction and Threshold set Jurisdictions should match.
  • User Mapped Jurisdiction will take the priority if they do not match.
• User not mapped with any jurisdiction will not see/get all jurisdiction's data.
• Provide the following grant through SYS user where the workspace schema is created.

  GRANT EXECUTE ON DBMS_RLS TO <ASC_Workspace_schema>;

  Note:

  If the accounts belonging to a customer do not belong to the same jurisdiction as the customer, but instead span multiple jurisdictions, the user executing the scenario should have access to all the relevant jurisdictions. If the user executing the scenario does not have access to the appropriate jurisdictions, then the scenario will not generate the expected number of alerts.

Optimizing SQL performance

You can further optimize SQL performance for ASC using this configuration. Users can configure SQL hints with PARALLEL or NO_PARALLEL hints. It comes with a default configuration as PARALLEL(8). Table ml4aml_hint_config holds the default configuration. Users can change these values as per database capacity and its DBA activity to come up with the best possible values that suit the database.

Note:

Ensure all the tables are properly indexed per data growth experience. We assume this is a standard DBA activity as on when data keeps growing.

Periodic Workspace Schema Cleanup

Note:

This section will be performed only during end of the tuning cycle.

The system creates some intermediate temporary tables as part of the ASC workflow, which should be dropped periodically during cleanup activity. The following sample oracle statement will generate a drop table statement including all temp tables.

The generated drop table statement should be manually verified before using it as a drop table statement.

To generate drop table statement, execute the following:

select 'DROP TABLE '||TABLE_NAME||';' from user_tables where table_name like
'%ASC_TEMP_%';

Example for the drop table statement:

DROP TABLE ASC_TEMP_1735;

Sync up Security Mapper between BD Production and ASC BD Schema

Note:

This step is optional and can be skipped if user management and security mapping for ASC-BD is self-managed.

• Generally, security mappings are done for BD production instances.
  • New user creations / user-security mapping happens in the BD Production
• ASC BD instance is generally a non-prod BD, like BD UAT, BD Pre-Prod, etc.
• If user management and security mapping happens outside of the ASC-BD instance ( say in BD Production ), then the security mapper table needs to be synced up between ASC-BD and BD-Prod. Here is the approach for sync up users.
  • Create a new Data Store in the Compliance Studio pointing to BD Production Schema.
  • During ASC workspace creation, add BD Production Data Source and source following tables:
    • kdd_jrsdcn
    • kdd_review_owner
    • kdd_review_owner_jrsdcn
• Execute Workspace data population batch to sync up the security mapper with ASC-BD.

  Note:

  This step must be repeated every time when users/security-mappings are created/modified.