BookmarkSubscribeRSS Feed
MG18
Lapis Lazuli | Level 10

 

Hi All,

 

We have recently loaded the DOW JONES Watch list data in Our AML system and we have 5,25,454 record in  FSC_ENTITY_WATCH_LIST_DIM table for DOW JONES (DWJN). Currently  We are under testing of this Integration and now i want to test the Scenario SAS10079 for the Dow Jones where I need help on below parts :-   

      1) How to test this scenario SAS10079 and what kind of data should be in FSC_PARTY_DIM table so it will generate alert for SAS10079 scenario ?

      2) Currently we are loading DOW Jones daily and monthly data in SAS AML system and i want to know how to load monthly data in AML system means whether we need to do truncate and load data  for each month load or we need incremental load or already defined sas macro will take care it ?

@Patrick @manishiiita@toorkp Please help on this part and many many thanks in advance.

 

Regards,

Mahesh  

 

 

13 REPLIES 13
manishiiita
Quartz | Level 8

Hi @MG18, I'm addressing both of your queries below:

 

1) How to test this scenario SAS10079 and what kind of data should be in FSC_PARTY_DIM table so it will generate alert for SAS10079 scenario ?

 

Do you know the functionality of any OOB watchlist scenario (SAS10079-82)? The matching logic is almost same in all these scenarios except for their types i.e. Scenario SAS10079 is for PEP on watchlist, SAS10082 is for Terrorist on watchlist and so on.

 

Coming to scenario SAS10079, below is the functionality of this scenario (copied from guide):

 

This scenario compares all customers, not already designated as politically exposed persons (PEPs) in the customer table, to the entity watch list table. For an individual, when checking for a full name match, both the full name columns (party_name and entity_name) as well as the first/middle/last name columns are compared. If a match is found on either exact name or name match code, then the scenario checks additional match components for potential matches. For individuals, the scenario checks for matches on country, state/province, and city match codes, as well as exact matches for birthdate or birth year and tax ID. For organizations, the scenario checks for matches on country, state/province, and city match codes, as well as exact matches for tax ID. A match is found if a customer is designated as a PEP in the entity watch list table and the minimum number of conditions to match for the entity is met. Note: this scenario requires that match codes are built for both the customer table and the entity watch list table. This scenario checks only for politically exposed persons who are not already marked as PEPs in the customer table.

 

Above description tells you almost everything about the scenario. Coming to your query, to test this scenario ideally you should have customers in your Party Table with (Full Name/Name+Match Code)+Additional Parameters matches as configured in scenario. Additionally, these customers should not be predefined as PEP 'Y' and in the watchlist table (Entity Watch List Dim) the respective record should have PEP flag as 'Y'. Then, there will be a match found for this customer against watch list data for PEP category.

 

2) Currently we are loading DOW Jones daily and monthly data in SAS AML system and i want to know how to load monthly data in AML system means whether we need to do truncate and load data  for each month load or we need incremental load or already defined sas macro will take care it ?

 

I believe, you would have loaded complete dump once then going forward you will have to load incremental data only. You can choose to load daily or weekly or monthly incremental files and your scenarios should also be run in the same frequency. I didn't get why are you loading both the files? I have worked mostly with Worldcheck files and there the data used to be like this.

 

Now, the question is how to load these incremental files? It depends on you scenarios. If you simply want to screen all your customers against the incremental data as you have already screened all your customers against existing watch list data, then you should simply update change_current_ind for all old records as 'N'. It will be 'Y' only for incremental watch list data. While scenario processing, it will pick records only with Change_Current_Ind 'Y'. Please note here you might miss screening of new customers against old watch list data. So, to avoid this you can chose another method to load incremental watch list data in which only those old records will be marked as 'N' where there is some update available in the incremental data. So, for scenario execution you will have at least one active record for all watchlist entities. This all can be done using OOB watch list data loading scripts.

 

Hope this will be helpful. Feel free to comment in case of any further queries.

MG18
Lapis Lazuli | Level 10

Many Many thanks for this reply .

MG18
Lapis Lazuli | Level 10

Hi ,

 

If you have any idea how to join FSC_ENTITY_WATCH_LIST_DIM and fsc_party_dim table .Please let me know .

Can we join these table for checking? 

 

Thnks. 🙂 

manishiiita
Quartz | Level 8

There is no way to join these two tables. That's why we have to check for matches for Names/Match Code/ City/ Nationality / DOB etc.

 

In SAS AML System, you don't need to join these two tables anywhere. You will be able to find only matches according to your matching conditions in watch list scenarios.

Patrick
Opal | Level 21

@MG18

I agree with @manishiiita

That's where the concept of Prep files comes into play. FSC_PARTY_DIM will feed into the Prep file, FSC_WATCHLIST_DIM will be the lookup table. 

 

"Joining" is done via match-codes as you need fuzzy matching. The rule then determines when such a match is considered to be an alert. That's what you'll find in the scenario code.

 

As for loading: Delta load is certainly faster. If you've got the time the I'd possible also go for a monthly (or whatever) full-load just as a safeguard in case a delta load goes ever wrong. A full load with expiring all records not in source will fix the DIM table for any delta load gone wrong.

MG18
Lapis Lazuli | Level 10

Hi All, 

 

@Patrick @manishiiita Thanks for your valuable reply which helps me to proceed on the issue.

I have added some 9 entries in the FSC_Party_dim table and tested the same scenario through Scenario Administer which has generated  alerts through the screen also as shown in below  But when i ran the AML AGP cycle for the same date it didnt generate any alerts for the same Scenario and there is no Error in AGP run log also. Why could be the reason for the same?

I have checked the data-set  STG_ALERT.PARTY_WATCHLIST_ALERTS_20180803 which has the 9 entries for the same parties and same entries are not present in the fsk_alert table.

 

 

 

 

alerts fro SAS10079.png

manishiiita
Quartz | Level 8

It looks like scenario is not supposed to run on the date you are running the AGP. Please check the frequency of scenario and FSK_JOB_CALENDAR table. If frequency for the scenario is Weekly or Monthly then Weekly/Monthly Rundate Indicator should also be set as 'Y' for the AGP date in FSK_JOB_CALENDAR table.

MG18
Lapis Lazuli | Level 10

For Testing purpose , I have the changed frequency of scenario to DAILY and in the log file scenario has been run for that date also.

 

I have checked the log file also at one point it has the 9 obs in both data-sets stg_aler.PARTY_watchlist_alerts20180803 and work.PARTY_watchlist_alerts20180803 and work.risk_factor is also having 9 obs for the same.

While creating the work.combined_alerts is not considering those 9 record from watchlist_alerts table. Why could be the reason for this ?

manishiiita
Quartz | Level 8

Please Check if the scenario has been configured as a scenario or risk factor? It should be configured as a Scenario not Risk factor to trigger alerts.

 

If this is properly configured then it should work. If it doesn't work then your can write to SAS Support.

MG18
Lapis Lazuli | Level 10

@manishiiita

Ok Thanks for the suggestions .

 

Please Check if the scenario has been configured as a scenario or risk factor? 

Are you referring RISK_FACTOR should be N in scenario configuration ? how can i check this ? 

manishiiita
Quartz | Level 8

Yes, I'm referring to RISK_FACTOR field. It should be set 'N' (No) to work as a scenario and trigger alerts. It can be done from scenario administration. Open the scenario and you will see RISK_FACTOR field which can be set to Y/N.

 

You can also check it at database level in FSK_SCENARIO table.

MG18
Lapis Lazuli | Level 10

Hi @manishiiita @Patrick

 

I am facing below mentioned Error in AML AGP run , If you have any solution to this issue  please let me know :- 

 

Error :- 

ERROR: AML: Number of incoming alerts: 9 are not equal to the number of outgoing alerts: 81
ERROR: AML: There may be a problem in the SEG_CORE.FSC_PARTY_ACCOUNT_BRIDGE
ERROR: AML: Compare STG_ALER.suppressed_alerts to STG_ALER.entity_alerts to determine which primary entity number(s) were dropped
GET_ENTITY_INFO VERSION 5.1HF2 J74002-J72002
ERROR: AML: A problem has occurred in get_entity_info.sas while processing alerts. Please see the SAS log for details.

 

I have already raised this concern to SAS technical team but those people are taking too much time to reply .

If anyone has faced this issue in the past and got any solution , Please share with me and it will be great help .

 

manishiiita
Quartz | Level 8

As the error is saying, "There may be a problem in the SEG_CORE.FSC_PARTY_ACCOUNT_BRIDGE" did you check for duplicates / incorrect mapping in Party /Account /Party Account Bridge tables?

 

These issues mostly come due to incorrect mapping / duplicates in above Dimension tables. Try to debug it step by step. Run the job in SAS EG and look into the work/temporary files.