Determining Entity Risk

Oracle Financial Services Behavior Detection clients can provide risk factors for business entities through the Oracle Financial Services Data Interface Specification (DIS). The risk can be assigned to the same business entity in the several ways. The Ingestion Manager resolves across these various risks to create an Entity Effective Risk.

Figure -22 Entity’s Effective Risk


Description of Figure -22 follows
Description of "Figure -22 Entity’s Effective Risk"

Oracle Financial Services Behavior Detection derives risk on the following business entities:

  • Customers
  • Accounts
  • Financial Institutions
  • Correspondent Banks
  • Derived Addresses
  • Derived Entities (Names)
  • Derived Entities (Identifiers)

The client can provide risk information directly through the Account and Customer input files as specified in the DIS. Accounts and Customers can also receive Know Your Customer (KYC) risk information through the Account Supplemental Attributes and Customer Supplemental Attributes DIS files. All of the business entity types can receive risk information through watch lists.

When determining an entity’s effective risk, the approach to resolving across multiple sources of risk varies based on the entity type. The general rules to follow are:

  • Watch List risk has higher priority than other risk factors.
  • Exemption and Trust take priority over risk.
  • More specific risk factors are preferred over less specific risk factors (for example, risk associated with an Identifier is more specific than risk associated with a Name).

Derivations of Customer, Account, and Correspondent Bank Effective Risk are the most complex. The following sections outline the rules for these derivations.

Deriving Customer Entity Risk

Customer records can provide risk through the following distinct mechanisms:

  • Business Risk or Geography Risk provided in the Customer DIS file
  • KYC Risk provided in the Customer Supplemental Attributes DIS file
  • Watch List entries matching the Customer ID or Customer’s Tax ID

If the Customer has any Watch List risk information, then the Customer’s Effective Risk is derived directly from the Watch List risk factors. If there is no Watch List risk information on the Customer, then the Effective Risk is derived as the highest of Business Risk, Geography Risk, and KYC Risk. KYC Risk can be provided as either Trust or Exclusion. If that is the case, the KYC trust is selected over positive risk factors in Business Risk or Geography Risk.

Deriving Account Entity Risk

Account records can provide risk through the following distinct mechanisms:

  • Business Risk or Geography Risk provided in the Account DIS file
  • KYC Risk provided in the Account Supplemental Attributes DIS file
  • Watch List entries matching the Account ID or Account’s Tax ID

Accounts can also inherit risk from the Primary Customer identified on the Account. This risk is referred to as Account Customer Risk. Accounts inherit the Effective Risk from the Primary Customer as it is calculated using the rules described in Deriving Customer Entity Risk with the following exceptions:

  • If the Customer’s Effective Risk was driven by KYC risk, then the Account processing re-calculates the Customer’s effective risk, ignoring KYC risk on the Customer. The reason for this is that the Account’s risk factors are part of the Oracle Financial Services KYC product’s risk derivations, so propagating that risk back to the Account is not productive. If the Customer’s Effective Risk was driven by KYC, then the Account uses the highest of the Customer’s Geography and Business risks as the Account Customer Risk.
  • There is a configurable parameter in the Ingestion Manager to determine whether or not Trust and Exclusion should be inherited from the Customer record. If this is configured to NOT inherit this effective risk and the Customer’s Effective Risk indicates Trust or Exclusion, then the Customer’s risk is not considered when determining the Account Effective Risk.

If the Account has any Watch List risk information, then the Account’s Effective Risk is derived directly from the Watch List risk factors. If there is no Watch List risk information on the Account, then the Effective Risk is derived as the highest of Business Risk, Geography Risk, KYC Risk, and Account Customer Risk.

Deriving Correspondent Bank Entity Risk

Correspondent Bank records can derive risk information through the following distinct mechanisms:
  • Watch List entries matching the Correspondent Bank ID
  • Watch List entries matching the Correspondent Bank Name
  • Watch List entries matching the Correspondent Bank Address
If the Correspondent Bank has any Watch List risk information, then the Correspondent Bank’s Effective Risk is derived directly from the Watch List risk factors. If there is no Watch List risk information on the Correspondent Bank identifier, then the Effective Risk is derived based on matching Watch List risk information pertaining to the Correspondent Bank name. If there is no Watch List risk information on the Correspondent Bank name, then the Effective Risk is derived based on the matching of the Correspondent Bank’s address information to Watch List entries.
Watch Lists

A Watch List is a list of entities that have known risk characteristics. Watch Lists can represent public sources or can be created and managed internally by the institution. Common public sources for watch lists include Office of Foreign Asset Control (OFAC) and Financial Action Task Force (FATF). The types of entities provided on Watch Lists include:

  • Identifiers (for example, SSN, Tax ID, and Passport ID)
  • Organizations (for example, business name, SWIFT code, and ABA number)
  • Accounts (for example, internal or external accounts)
  • Persons (for example, personal name)
  • Geography (for example, countries, state, city, postal code, and address)
  • Combined Names and Geography

Refer to the Data Interface Specification for more information on Watch Lists and Watch List Entries. Oracle Financial Services Behavior Detection categorizes Watch Lists into the following types:

  • Exempted Watch List: Entities on Exempted Watch Lists are highly trusted clients on whom no Money Laundering alerts will be generated.
  • Trusted Watch Lists: Entities on Trusted Watch Lists are known to be highly trustworthy. Certain scenarios can be configured to exclude trusted entities from monitoring.
  • Risk Watch List: These are the entities that carry a risk value indicating that they should be monitored more closely than the general population. Money Laundering scenarios allow for separate threshold values to be set when monitoring entities with a certain risk level. Risk lists are risk weighted using values ranging from one (lowest risk) to ten (highest risk).

    Note:

    There is no risk list with a risk level of zero. Risk level zero is reserved to indicate that there are no known risk factors to consider. It is also the default risk level for all entities in Oracle Financial Services Behavior Detection.

The matching criteria of Watch List Entry are as follows:

  • All ID entries on a Watch List require an exact match to an entity.
  • All Name entries on a Watch List require an exact or a fuzzy match to an entity.
  • Addresses can be matched to watch list entries at multiple levels (for example, the same address can match one watch list entry for a Street Address and can match a separate entry for a Country)

For each Watch List match to an entity, a List Membership Record is created, which includes the following:

  • ID of Watch List matched
  • Date when the entity was added to the Watch List
  • Date when the entity was removed from the Watch List
  • Watch List entry that was matched
  • Type of Watch List Entry that was matched

Fuzzy name matching is a technique to account for normal variations in names and still successfully match the names against watch lists. For more information on configuring Fuzzy Name Matching within Oracle Financial Services Behavior Detection, refer to the Administration Guide.

Determining Watch List Risk

Oracle Financial Services Behavior Detection defines each reference entity with an adjudicated Watch List Risk. An entity’s Watch List Risk is determined through a hierarchy of rules as follows:

  • If an entity is a member of a Watch List of type Exempt, then the Watch List Risk value is -2. This value is not displayed; it is used for internal processing.
  • If an entity is a member of a Watch List of type Trusted, then the Watch List Risk value is -1. This value is not displayed; it is used for internal processing.
  • If an entity is matched to multiple entries on one or more Watch Lists, the match that is the most specific is used to drive risk. The order of preference is:
    1. ID match
    2. Exact Name match
    3. Fuzzy Name match
    4. Street Address match
    5. Postal Code match
    6. City match
    7. State/Province match
    8. Country match

Not all entity types can match multiple types of watch list entries. For example:

  • Accounts and Customers only match identifiers.
  • Correspondent Banks can match either IDs, Names, or Addresses.
  • Addresses can match at different granularities, ranging from Country to the specific street address.
  • If multiple risk lists are matched with the same specificity, then the final Watch List Risk is the highest of the risks of the entities matched at the same level.

    Note:

    All matches are retained and stored in List Membership Records associated with the entity.
Determining Risk on Transactional Data

After Effective Risk is derived for Entities, this risk is reflected on instructions and transactions. The risk is generally calculated for each party on the transaction and stored as a Party Entity Risk. The Entity Risks of each party is then used to calculate an Activity Risk for each party. Activity Risk is an assessment of the risk level of the activity in which that party has engaged. As such, that party’s own Entity Risk is not considered when calculating the Activity Risk for the party.

The derivations for Party Entity Risk vary by the transaction type.

Determining Front Office Transaction Party Entity Risk

Front Office transactions contain the following distinct sources of risk for any one party:

  • Party ID
  • Party Name
  • Party Location

As a general rule, Oracle Financial Services Behavior Detection uses the most specific risk factor possible when setting the Party Entity Risk. As such, risk information about the Party ID is considered more reliable than risk information about the Party Name or the Party Location. The Ingestion Manager can be configured to automatically accept the Party ID Risk only when it is above a certain threshold (this defaults to zero, meaning that non-zero Party ID Risk is always accepted as the Party Entity Risk).

For each Party, a Geography Risk is calculated using Watch List information as described in the Watch Lists section.

Party Entity Risk is determined by a hierarchy of rules as follows:

  • If the Party ID Effective Risk is Trusted or Exempt, then set Party Entity Risk to the Party ID Effective Risk.
  • If the Party ID Effective Risk is > Party ID Win Threshold, then set Party Entity Risk to Party ID Effective Risk.
  • If the Party Name combined with the Party Location matches a combined Name-Location Watch List record that represents Trust or Exclusion, then set the Party Entity Risk to the combined Name-Location and Trust-Exemption level.
  • If the Party Name combined with Party Location matches a combined Name-Location Watch List record that represents Risk, then set the Party Entity Risk to the HIGHER of the Party ID Effective Risk and the combined Name-Location Risk level.
  • If the Party Name Effective Risk alone is Trusted or Exempt, then set the Party Entity Risk to the Trust-Exemption level of the Name.
  • If the Party Name Effective Risk indicates risk, set the Party Entity Risk to the HIGHER of the Party ID Effective Risk and the Party Name Effective Risk.
  • If the Party Geography Risk is Trusted or Exempt, then set the Party Entity Risk to the Trust-Exemption level of the Geography.
  • Set the Party Effective Risk to the HIGHER of the Party ID Entity Risk and the Party Geography Risk.

The Party Entity Risk is calculated for every party on each Front Office Transaction. This value displays when showing Front Office Transactions in the UI. This value is then used to calculate Party Activity Risk for each party on the transaction. Refer to Determining Activity Risk on Front Office Transactions for details on the calculation of Party Activity Risk for Front Office Transactions.

Determining Back Office Transaction Party Entity Risk

Back Office Transactions contain only two parties, the Account that is the focus of the activity and the Offset Account involved in the transaction. As these are both Identifiers, setting the Party Entity Risk for Back Office Transactions is propagating the Account Effective Risk values for the related accounts to the transaction.

Determining Settlement Instruction Party Entity Risk

Based on how Settlement Instructions are used in scenarios, the processing of parties is handled somewhat differently than Front Office Transactions. Although there are multiple parties on a Settlement Instruction, there is only a Party Entity Risk calculated for the Account holding the Instruction. The processing is, therefore, simply to propagate the Account’s Effective Risk to the Settlement Instruction Entity Effective Risk.