Oracle Financial Services Oracle Financial Services Behavior Detection uses risk calculations as part of managing sensitivity when detecting behaviors of interest in Money Laundering and Fraud scenarios. Risk Information can be provided through watch list or an attribute of the record provided to the ingestion manager for given customers and accounts.
Based on several risk inputs, Oracle Financial Services Oracle Financial Services Behavior Detection calculates effective risks for business entities and calculates both Party Risk and Activity Risk on Transactions and Settlement Instructions.
Figure 1 displays the basic flow of the calculation.
Figure 1: Risk Derivation-Overview
In addition to risk, Oracle Financial Services Oracle Financial Services Behavior Detection supports the concepts of Exempt Entities and Trusted Entities. These concepts are discussed in more detail in section Watch Lists. In brief, Exempt Entities are those that should not be alerted in Anti-Money Laundering scenarios. Trusted entities are those that meet specific criteria which demonstrates that they are more trustworthy than the general population.
Risk levels use a ten-point scale, with one representing moderate risk and ten representing highest risk. Entities that have no known risk receive a risk score of zero.
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 2 reflects the basic flow for deriving Entity Effective Risk.
Figure 2. 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.
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.
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.
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.
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 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 Oracle Financial Services Behavior Detection, refer to the Administration Guide.
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:
a. ID match
b. Exact Name match
c. Fuzzy Name match
d. Street Address match
e. Postal Code match
f. City match
g. State/Province match
h. 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.
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.
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 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 section Watch Lists.
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 section Determining Activity Risk on Front Office Transactions for details on the calculation of Party Activity Risk for Front Office Transactions.
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.
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.
Activity Risk identifies the risk of the Activity as seen from the viewpoint of each Party on a transaction. In general, the Activity Risk is the highest risk of the other parties on the transaction or of the transaction Channel or Product itself. As with calculating Party Entity Risk, the derivation of Party Activity Risk varies by transaction type.
Front Office Transaction Party Activity Risk calculates risk separately from the point of view of each party on the transaction. The risk is intended to identify how risky the activity is independent of risk factors already associated to the Party through the Party Entity Risk. As such, on Front Office Transactions, the risk is calculated using the Party Entity Risk of the parties on the other side of the transaction. The general approach is to use the highest of the Channel Risk, Product Risk, and Party Entity Risk of the other parties. Channel and Product Risk are provided in the DIS file for Front Office Transactions.
Several party roles effect activity risk. The following sections describe the relationship between varying party roles and activity risk for transactions.
Table 1 displays the party role-activity risk relationship for an electronic funds transaction.
Table 2 displays the party role-activity risk relationship for the cash transaction.
Party Role |
Roles impacting Activity Risk |
|---|---|
Originator |
Location, Conductor |
Location |
Conductor, Originator, or Beneficiary |
Conductor |
Location, Originator, or Beneficiary |
Beneficiary |
Location, Conductor |
NOTE:
A Cash Transaction record can have an Originator or a Beneficiary, but not both.
Table 3 displays the party role-activity risk relationship for the monetary instrument and check transactions.
Activity Risk on Back Office Transactions is only calculated for the Account that is the focus of the activity. Since the only other risk factors available are the Offset Account’s Effective Risk and the Channel and Product Risks provided on the transaction, the Activity Risk is calculated as the highest of these factors.
The Activity Risk calculated for Settlement Instructions is from the point of view of the Account holding the instructions. Calculating Activity Risk on Settlement Instructions follows a similar approach as Front Office Transactions whereby the Entity risk is calculated for each party and then used to calculate Activity Risk; however, on Settlement Instructions, the Entity Risks for each party are not stored. The Entity Risks are calculated as follows:
The Destination Customer Entity Risk is calculated using the following hierarchical rules:
1. If the Destination Customer Account Effective Risk is non-zero, then set the Destination Customer Entity Risk to Destination Customer Account Effective Risk.
2. If the Destination Financial Institution Effective Risk is non-zero, then set the Destination Customer Entity Risk to Destination Financial Institution Effective Risk.
3. If the Destination Customer Name Risk ³ Destination Financial Institution Name Risk, then set the Destination Customer Entity Risk to Destination Customer Name Risk.
4. If the Destination Financial Institution Name Risk > Destination Customer Name Risk, then set the Destination Customer Entity Risk to Destination Financial Institution Risk.
5. Set the Destination Customer Entity Risk to zero (0).
The Physical Delivery Party Entity Risk is calculated using the following hierarchical rules:
1. If the Physical Delivery Account Effective Risk is non-zero, then set the Physical Delivery Party Entity Risk to Physical Delivery Account Effective Risk.
2. If the Physical Delivery Financial Institution Effective Risk is non-zero, then set the Physical Delivery Party Entity Risk to Physical Delivery Financial Institution Effective Risk.
3. If the Physical Delivery Geography Risk is non-zero, then set the Physical Delivery Party Entity Risk to the Physical Delivery Geography Risk.
4. Set the Physical Delivery Party Entity Risk to zero (0).
The final Activity Risk setting on the Settlement Instruction is the highest level of the following risks:
· Destination Customer Entity Risk
· Physical Delivery Party Entity Risk
· Settlement Country Geography Risk
· Product Risk
· Channel Risk
This final Activity Risk is used in scenarios to determine the risk level of the Settlement Instruction without regard to the risk factors inherent in the Account holding the Instruction.