3.4 OFS Real Time Fraud (RTF)

This section describes the RTF-related post-installation steps.

If OFS RTF is installed:
  1. Redeploy the war files - RTFWIRE.ear and RTFCARD.ear. Do not deploy RTFRAUD.war.

    Note:

    RTF CARD and WIRE are not supported on Tomcat in OFS BD 8.1.2.10 ML.
  2. Execute steps a and b only if migration is not done as part of 8124 patch.
    1. Follow these steps to migrate existing Fraud data to the new UI. This step must be performed only once. During reinstallation, skip this step.
      1. Execute the command from SYS DB: GRANT CREATE JOB TO$ATOMIC_SCHEMA.
      2. In Real Time Fraud PMF Migration.sql Real Time Fraud PMF Migration.sql, replace all $ATOMIC_SCHEMA with current atomic schema name.

        Note:

        • The atomic schema name is case sensitive and must be in Capital letters.
        • During upgrade from OFS BD 8123, remove the following from the Migration.sql file. This must be performed only when upgrading directly from OFS BD 812.

        CREATE TABLE FCC_FR_RULE_ID_MAP ( "N_OLD_RULE_ID" NUMBER(28,0) DEFAULT NULL,

        "V_TRXN_TYPE" VARCHAR2(50) DEFAULT NULL,

        "N_NEW_RULE_ID" NUMBER(28,0) DEFAULT NULL NOT NULL ENABLE

        )

        /

    2. If Oracle Financial Services Real Time Fraud (RTF) CARD or WIRE version <= 8.1.2.3 is installed, follow these steps for PMF migration.

      Note:

      Before installation close all pending alerts in the system. Before running the PMF migration steps, do not click on any old alerts from the UI post installation.

      From OFS RTF 8.1.2.4, Jurisdiction and Business Domain are mandatory fields. In the migration script, update the first query for WIRE_MIG_TASK in post installation section under --WIRE FCC_FR_ALERTS with the correct jurisdiction and business domain code for the old alerts. Provide the values with double single quotes ('').

      For example: For giving value of 'a' for business domain and 'AMEA' for jurisdiction (values must be from BUS_DMN_CD in KDD_BUS_DMN and JRSDCN_CD in KDD_JRSDCN tables respectively).

      l_sql_stmt := ' INSERT INTO FCC_FR_ALERTS ( N_ALERT_ID, T_ACTION_TAKEN, V_STATUS, JRSDCN_CD, BUS_DOMAIN_CD, V_ASSIGNEE, RUNTIMESTAMP, V_ACTION, V_DECISION_CD, V_TRANS_TYPE ) SELECT FCC_FR_ALERT_ID_MAP.N_NEW_ALERT_ID, T_ACTION_TAKEN, FCC_FR_TRANSACTIONS_8124_BACKUP.V_STATUS, ''AMEA'', ''a'', V_ASSIGNEE, RUNTIMESTAMP, V_ACTION, CASE WHEN T_ACTION_TAKEN IS NULL THEN NULL ELSE V_ACTION END, ''WIRE'' FROM FCC_FR_TRANSACTIONS_8124_BACKUP INNER JOIN FCC_FR_ALERT_ID_MAP ON FCC_FR_ALERT_ID_MAP.N_TRANSACTIONSEQID = FCC_FR_TRANSACTIONS_8124_BACKUP.N_TRANSACTIONSEQID WHERE FCC_FR_TRANSACTIONS_8124_BACKUP.ROWID BETWEEN :start_id AND :end_id AND FCC_FR_ALERT_ID_MAP.V_TRXN_TYPE=''WIRE''';

      PMF Migration
      • Execute in ATOMIC SCHEMA. Replace $CONFIG_SCHEMA with Config Schema name.

        GRANT SELECT, UPDATE on FCC_FR_ALERT_ID_MAP to $CONFIG_SCHEMA

        /

      • Execute in CONFIG SCHEMA. Replace $ATOMIC_SCHEMA with Atomic Schema name.

        CREATE OR REPLACE SYNONYM ALERT_ID_MAP FOR $ATOMIC_SCHEMA.FCC_FR_ALERT_ID_MAP

        /

      • Ensure that PMF matches value before update.

        For example: If L1 PMF had OFS ECM enabled for CARD for OFS BD version < 8124, enable it. Then restart FICServer and App server before calling the command.

      • Execute the updated Real Time Fraud PMF Migration.sql in the atomic schema.
      • The PMF POST request is a long running process (~1100-1200 alerts/min at 10 threads, 10,000 step size). When the total number of records is very large, performing the migration in one go can be avoided by updating V_STATUS in FCC_FR_ALERT_ID_MAP to 'SKIP' for records that are not to be processed at the time. Change this back to NULL before resuming.
      • Migration POST request:

      Address: hostname:port/$BDCONTEXT/rest-api/FRAUDREST/RealTimeFraudPMFMigration

      Request body for Card:

      { "transactionType": "CARD", (Required) "Threads": 10, (Optional param, default value 10 if not provided) "Stepsize": 10000 (Optional param, default value 10000 if not provided) }

      Request body for Wire:

      { "transactionType": "WIRE", (Required) "Threads": 10, (Optional param, default value 10 if not provided) "Stepsize": 10000 (Optional param, default value 10000 if not provided) }

      Note:

      Generally, increasing parallelization does not increase throughput as bottleneck is in the PMF API which is serialized. So, default values are preferred. The number of threads does not increase unless a high config box (The API was tested with 8 CPU LINUSX KVM (64 total))is used. If thread size is increased, make sure to increase the number of connections for FICMASTER in WebLogic console. This must at minimum be 5 more than the number of threads. Stepsize must be 500-1000x the number of threads.
      • Status of migration can be monitored using logs or by manually checking the tables in DB.
        • For alerts which have migrated successfully/error/no update for card:

          SELECT COUNT(*) FROM FCC_FR_ALERT_ID_MAP WHERE V_STATUS IS NOT NULL AND V_TRXN_TYPE = 'CARD'

        • For alerts which are yet to migrate and are being processed for card:

          SELECT COUNT(*) FROM FCC_FR_ALERT_ID_MAP WHERE V_STATUS IS NULL AND V_TRXN_TYPE = 'CARD'

        • For alerts which have migrated successfully/error/no update for wire:
        • SELECT COUNT(*) FROM FCC_FR_ALERT_ID_MAP WHERE V_STATUS IS NOT NULL AND V_TRXN_TYPE = 'WIRE'
        • For alerts which are yet to migrate and are being processed for card:

          SELECT COUNT(*) FROM FCC_FR_ALERT_ID_MAP WHERE V_STATUS IS NULL AND V_TRXN_TYPE = 'WIRE'