Most financial institutions review their scores on a periodic basis to keep up to date with trends and developments in money laundering and terrorist financing. Because of this need, SAS Anti-Money Laundering enables administrators to change the score attributes. In this post, I’ll review how to edit the score for a risk attribute, specifically the Country or Region score of the Bahamas.   On the menu bar, I click Search, and in the Search field, I enter Bah* and press Enter. The wildcard character asterisk returns multiple characters, including zero characters, so this search returns any objects in the system that start with the letters Bah (To learn more about searching, please review this other post I wrote: Searching in SAS Anti-Money Laundering: Global Search.   Because I know I’m looking for a country lookup score, in the Filters pane, I select CRR Lookup. Then, in the search results, I double-click the first result (Country or Region score BS Bahamas).   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.       On the toolbar, I click the Edit button because I must be in edit mode to edit this score.   For Numeric value, I enter the new value of 250. Then, I’ll save this lookup score.     Next, I’ll verify this change in the end user interface. I’ll start by refreshing the browser, and then on the menu bar, I click Search. In the Search field, I enter Bah* again and press Enter. In the Filters pane, select CRR Lookup.   Then, in the search results, I select Country or Region score BS Bahamas and see the updated score.     To learn more about the CRR lookup entity and how to add a risk attribute to your system, please review this post: Adding a New CRR Lookup Entity.   To view more information about our SAS Anti-Money Laundering solution in general, please visit https://support.sas.com/en/software/sas-anti-money-laundering-support.html.     Find more articles from SAS Global Enablement and Learning here. ... View more

  In SAS Anti-Money Laundering, the risk rating process is based on a scorecard. This scorecard uses data on individual customers and organizations.   For individuals, this information pertains to their residence, citizenship, profession, and the products the customer has taken out. For an organization, this information includes the type of industry in which they operate and their legal entity type. Each of these values comes with its own score, as these attributes themselves are risk rated.   In this post, I’ll discuss how these attribute risk scores are stored in the system, and the two ways in which a financial institution can add an attribute risk score. I’ll also review a quick example. The attributes and scores are stored in the CRR Lookup table in the fdhdata schema. See a partial screenshot of the crr_lookup table below.     The CRR Lookup is an entity that contains scores for the various attributes that make up a customer’s customer due diligence, or CDD,  profile.   It is important to note that the scores for the various attributes are not standardized. Each financial institution is responsible for determining the scores for each of these attributes that together make up the profile of a customer.   In addition, not every financial institution will have the same attributes or ranges within an attribute. This is because not all financial institutions provide the same products and services. For example, financial institutions that do not provide insurance products have no need to risk rate them.   Lastly, country scores will also vary. Scores for different countries change depending on the country of reference. For example, customers in Columbia pose a different risk in US markets than in Russian markets. Also, financial institutions don’t typically set a score for the home market country, as that is the frame of reference.   Most financial institutions review their scores on a periodic basis to keep up to date with trends and developments in money laundering and terrorist financing. Because of this need, SAS Anti-Money Laundering enables administrators to set and change the score attributes.   One way is that administrators can load the CRR Lookups into the Postgres database in bulk. If the number of objects to be added or edited is relatively small, the best practice is to add or change these manually through the end-user interface. A new CRR Lookup can be added by clicking the CRR Lookup button under Create New Objects on the Home page. It is important to note that users need the appropriate permissions to create new CRR Lookup objects. Also, this solution does not allow bulk editing of scores.   Let’s take a look at how to add a new CRR lookup entity manually. I’m going to add a new occupation, AML IT Consultant, and give it a score of 200.   On the Home page, under the Create New Object section, I click CRR Lookup.     For Table name, I leave Occupation score. It’s important to note that this is a virtual table, which is actually a value for the column table name in the crr_lookup table in the fdhdata schema.   For Code, I enter AML IT CONSULTANT, and for Numeric Value, I enter 200. Then, I’ll save.     Now I want to navigate back to the search page and search for this newly added occupation to confirm that it was created.   On the menu bar, click Search. In the Search field, enter *, and press Enter. In the Filters pane, select CRR Lookup. Then, expand CRR Lookup to see the filter facets and select Occupation score.   Notice that there are 17 occupation scores. I see the occupation score AML IT Consultant.     To view more information about scoring and our SAS Anti-Money Laundering solution in general, please visit https://support.sas.com/en/software/sas-anti-money-laundering-support.html.     Find more articles from SAS Global Enablement and Learning here. ... View more

  SAS Anti-Money Laundering offers an alert scoring feature. The alert scoring feature provides you with a means to assign a priority score to active alerts. This enables you to better align team resources to improve your business efficiency by calculating which entity alerts represent the most risk to your institution. In this post, I’ll review the alert priority scoring process, and the jobs that are implemented as a part of this feature.   The alert priority scoring process is accomplished by two jobs: the fcf_aml_alert_enrich job and the fcf_aml_alert_scoring job.   Let’s first discuss the fcf_aml_alert_enrich job. The first part of this job is data extraction. The input parameters of this job define what is extracted depending on whether the input parameter’s value matches the value in the data.   There are default values for the fcf_aml_alert_enrich job input parameters (see the table below). The two parameters that I’d like to point out are lookback_window and txn_pull_window. The lookback_window parameter defines the number of past transactions to be stored for feature enrichment calculation, and the txn_pull_window parameter defines the number of days for past transactions (per entity) to be included. You can also filter alerts on the domain type (tm_domain) and choose the entity level for the statistical calculation of behavior (either at the Customer or Account level).   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   The fcf_aml_alert_enrich job retrieves both active and dispositioned alerts from the svi_alerts.tdc_alert (active alerts) and svi_alerts.tdc_alert_action (historical alerts) tables, as well as related transactional and entity-level information from the core tables.   After the data is extracted, the feature enrichment process begins.   Why do we enrich our features before plugging them into our alert scoring model? The simplest explanation is that our model will only be as good as the quality of data and features that it reads as input. In other words, by enhancing the separability of the classes, our machine learning model is more likely to perform well and produce meaningful answers.   SAS Anti-Money Laundering provides a set of predefined macros that perform various feature calculations and provide maximum flexibility for users to pass custom parameters to create several variations of a feature.   Some enrichment macros are used to calculate scenario-related features, such as the sum of cash deposits in the last N days. Other macros are used to calculate behavioral features, such as the max, min, and average of transaction count for the past N days, for a given account type and channel name.   The output of the fcf_aml_alert_enrich job is two enriched data sets. One data set contains the enriched active alerts (ACTIVE_ENRICH_ENTITY) and the other data set contains the enriched historical alerts (HIST_ENRICH_ENTITY).   The fcf_aml_alert_scoring job scores the active alerts present in ACTIVE_ENRICH_ENTITY by training a model using the HIST_ENRICH_ENTITY data set.   The fcf_aml_alert_scoring job can be configured to use either the out-of-the-box model or a user-developed model. When the model finishes scoring, the results are appended to alerts in a field named enrichment_json_doc. You can also view details about the model in the tdc_enrichment_field table.   To comply with regulatory requirements, all the model score history is stored persistently in the database.   It’s important to mention that to view the alert priority scores in SAS Visual Investigator, you must add the field via the Alerts grid through the strategy. You do not need to re-index for the scores to appear.   Now let’s look how to run these jobs in SAS Job Execution. Typically, the URL to access SAS Job Execution includes the name of the deployment domain, and then SASJobExecution with an ending slash (i.e. http://server/SASJobExecution/).   After you’ve signed into SAS Job Execution as an administrator user, in the Content panel on the left, you’ll navigate to SAS Content, Products, SAS Anti-Money Laundering, and then Jobs. Under Jobs, you first execute the fcf_aml_alert_enrich job and then the fcf_aml_alert_scoring job.     To run these jobs, you’ll right-click the job, and select Submit job.   It’s important to note that these jobs should be run after the alert service is done processing alert aggregation at the entity level. In other words, these jobs should be run after the AGP completes successfully.   To view more information about alerts and our SAS Anti-Money Laundering solution in general, please visit https://support.sas.com/en/software/sas-anti-money-laundering-support.html.     Find more articles from SAS Global Enablement and Learning here. ... View more

  Many SAS Solutions use APIs to interface with 3rd party software or other SAS solutions. For instance, there’s a REST API for SAS® Anti-Money Laundering that retrieves a list of unique scoring dates for a specific customer. And, in SAS® Visual Investigator, you can use a REST API to create a data store connection, instead of creating the connection manually. The possibilities are endless with what you can do with APIs, however, APIs can be difficult to understand at first! In this post, I’ll start with the basics and give an introduction to APIs.   API stands for application programming interface.   APIs are a set of rules and protocols that enable different software components to communicate with each other. To us, APIs simply look like code or a particular programming language, but for computers, APIs provide a way to share data or functionality. An API works as a facilitator connecting software platforms that would otherwise not be able to interact, which enhances the user’s experience.   You probably use APIs daily without even knowing. For example, when you check the weather app on your phone, it’s most likely using an API to get the most current weather data from a service. Or, if you’re online shopping, and you use an online payment method. These payment systems are embedded into many websites that require financial transactions. The website interacts with the system, which connects to your personal financial information. The website itself does not have direct access to your financial information.   A common metaphor used to understand an API is ordering food at a restaurant. This metaphor involves you (the customer), the waiter, and the chef. You represent the client, the waiter in this metaphor represents the API, and the chef represents the server.   Let’s say that the waiter comes to your table, and you order a burger. The waiter gets your request for a burger and takes it to the chef, the person who’s making the burger. The waiter just helps you out with the different requests. When the burger is done, your waiter brings you food in the form of a burger, and you get to consume that burger in any way, shape, or form (that is, using your hands or using utensils).   Just like the waiter is the facilitator to connect you to the chef, APIs are the facilitators between software platforms to interact.   So far, I've covered a very brief overview of APIs. Let's now review an example of how to create a new Visual Investigator datastore by using a REST API request. I use Visual Studio Code in this example, but you can use any API application.   As with any REST API endpoint, I first need a valid access token to authenticate the request, which I’ve already obtained. There are many ways to obtain an access token. Please review the Initial Steps section of Maggie Redford's post for one example: Getting started with the REST APIs of Visual Investigator.   I’ll also need the credentials for the database I intend to connect to Visual Investigator with the newly created data store. I already have this information as well.   I’ll create a new request in Visual Studio Code by clicking File, New File. I enter create_datastore.http for the file name, and press enter. Note the http extension. Then, I click Create File.   Next, I define a few variables that will be used in the request.   The first variable is the baseUrl. In the file, I enter @baseURL = https://server.demo.sas.com. Next, I’ll define the access token, by entering @accessToken= and then copying the access token I obtained previously.   I enter POST and then add a reference to my base url and add the endpoint, which is svi-datahub/admin/dataStores.   On the next line, I add the Content-Type header and enter application/json. Next, I add the Authorization header and enter Bearer and reference my access token.   I add an extra line before I enter the request body. Do not forget this extra line!   I add the name of the database, which in this example is insurance. Then, I enter the database type, which is RELATIONAL, and the version which is 0.   Next, I add the connectionType, which is postgres and the host, which is server.demo.sas.com.   Then, I add the port number, which is 30432 and the username and password of the database we are connecting to, which is pgadmin and Student1.   Then, I add the databaseNameOrServiceName which is postgres, and the schema which is insurance.   Lastly, I include urlAppendedParameters which is ssl=prefer.   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   Note the quotation marks in the request body.   After I save this request, I right-click and select Send Request. The database is then created!       This was a very brief overview of APIs. To learn more, please see the SAS developers documentation for REST APIs: Rest APIs | SAS   Below are the resources I used for this post:   Brewster, Cordenne. 2021. “7 Examples of APIs in Use Today.” trio (blog). https://www.trio.dev/back-end/resources/api-examples. Last modified August 13, 2021.   Khalid, Yasoob. 2023. “API For Dummies: Learning The Basics Of API.” ScrapingBee (blog). https://www.scrapingbee.com/blog/. Last modified January 29, 2023.   Taulien, Kalob. 2020. “The simplest way to think about an API (the metaphor).” O’Reilly Media, Inc.  https://learning.oreilly.com/videos/understanding-apis-and/9781800564121/9781800564121-video2_1/     Find more articles from SAS Global Enablement and Learning here. ... View more

The e-filing process in SAS Anti-Money Laundering involves four main steps. First, the individual regulatory reports must be validated to conform to the data quality standard. Next, e-files are generated from the reports that are ready to submit. Then, you schedule the batch transfer process to submit the e-files to the regulators. Lastly, the system analyzes the response file from the regulators and updates both the case and report status in the interface.   The purpose of this post is to discuss each of these steps, including the jobs and macros that must be run to achieve these steps.   First, the regulatory reports included in the e-file must be validated. You click Validate link from the user interface, which executes the rr_job_validate_driver macro. This macro requires the rr_sar_validate.xsl and EFL_SARXBatchSchema.zip files, which are needed to validate the SARX report UI data and display FInCEN-provided error codes and item numbers. Both files must be in the xml folder located at SAS Content\Product\SAS Anti-Money Laundering\xml folder in SAS Job Execution. Also, the rr_error_code table is needed by this macro, which contains error codes and descriptions. This table is in the kc schema.   Next, is the step to generate e-files. A nightly batch job, rr_job_efile_fincen_driver, runs. The job selects all the reports with the correct status and includes them in an e-file. It’s important to mention that if the e-file has an attachment, then it is a ZIP, and the user must extract the XML and the zip-inside-the-zip containing the CSV attachment.   The rr_job_efile_fincen_driver calls the rr_efile_fincen_driver macro, and the rr_efile_fincen_driver macro consists of five other macros that are responsible for e-file generation.   rr_efile_fincen_driver is the main macro that executes e-file generation. This macro looks at all the ready to submit reports and executes based on report types.   The rr_datahub_type_access macro checks whether the user has the permission to update a regulatory report and to create and update an e-file.   The rr_efile_fincen_gen_xml macro generates the raw XML file based on the report data, and it further transforms the raw XML info the format required by the regulators.   The rr_efile_fincen_sar_attach macro adds a ZIP file to the report with an attachment.   The rr_efile_file_updt macro copies e-files from the work directory to the SAS folder.   The rr_efile_db_updt macro generates the JSON request to update reports and e-files in the database. This macro also updates the report status to “E-file generated.”   The next step is submitting the e-file to regulators. The e-file can be sent to FinCEN via either manual submission or Secure Direct Transfer Mode (SDTM). After the e-file is sent to FinCEN, the agency reviews the e-file and produces an acknowledgement/response file. The e-filer downloads the acknowledgment file and then saves this file to a particular location in SAS Drive   After the acknowledgment file is in the correct location, the response file gets analyzed. Another nightly batch job, rr_job_resp_fincen_copy_xml, uploads the response files from the operating system to the SAS Viya file system.   Then the rr_job_resp_fincen_process job runs to process all the files in the response folder and updates the e-file status and report status accordingly.   It’s important to mention that these jobs can be run outside of batch using SAS® Job Execution Web Application.   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   To learn more about the e-filing process and SAS Anti-Money Laundering in general, please visit https://support.sas.com/en/software/sas-anti-money-laundering-support.html.   Find more articles from SAS Global Enablement and Learning here. ... View more

  Segmentation is the process of grouping customers that have similar characteristics and transactional behaviors. Each grouping is known as a segment. These segments can then be used in various processes, such as creating and optimizing scenarios. The purpose of this post is to discuss the auto segmentation feature in SAS® Anti-Money Laundering, including how to run the jobs that execute this feature.   The auto segmentation feature implements a process to create and manage customer segments. It uses a combination of business-provided rules (which are fixed rules that separate customers into different segments based on prior business knowledge) that create high-level general segments and an unsupervised clustering-based algorithm that creates additional groupings within these segments. One purpose of segmentation is to detect and highlight outliers. In addition, if your organization has a very large amount of data, customer segmentation can be a used as a proactive step to help break up the alert generation process.   This auto segmentation feature involves three jobs: the segment generation job, the segment assignment job, and the segment reassignment job. These jobs are executed from the SAS Job Execution Web Application, which you can access by navigating to https://(your server)/SASJobExecution/   After you’re in SAS Job Execution, to get to the segmentation jobs, on the Content tab, you expand SAS Content, Products, SAS Anti-Money Laundering and then jobs. To run the jobs, right-click the job, and select Submit job.   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   Let’s look at the segmentation jobs in more detail.   The segment generation job, fcf_aml_segmentation, is the primary program in the auto segmentation feature. Before you execute this job, you must include predefined segment definitions as input.   Predefined segments are user-defined segments in the form of fixed business rules that are designed to create the first level of customer segments.   The segment generation job then creates sub-segments or groups for each of these predefined segments using an unsupervised clustering-based algorithm. If predefined segments are required, you must ensure that the definition file is specified. Predefined segments are specified in an input file that is placed in a SAS Drive folder location accessible within the SAS Anti-Money Laundering solution. The file name and location can then be specified via input parameters to the generation job. When predefined segments are not required, a definition file does not need to be specified. However, the input parameter value for the definition file name should be set to blank.   Next, you execute the fcf_aml_segmentation job. This program analyzes all the active customers within each predefined segment to create segment groups.   The data for this job is extracted from the svi_alerts and core schemas and then is enriched. The enriched data is then used to create segments.   Once the segments have been defined, the data is assigned to a segment. If there is not enough behavioral information to segment the data, it’s stored in an “unclassified” segment.   The generated segments are saved in the party_segment table, inside the Kc schema, where it and the segment data are available to SAS Anti-Money Laundering. A party can have multiple segments stored in this table. However, only the most current segment, or segment with change_current_ind = Y, is active.   It’s important to note that the fcf_aml_segmentation.sas job must be run at least once before running any other job, because it generates artifacts that are dependencies for the remaining jobs.   The segment assignment job, fcf_aml_seg_assign_unassigned, is used when more customers have been added to the core schema. It executes a process that is similar to the primary job, except that the data is filtered on new and unclassified customers. The segment definitions from the primary job are used to assign the data.   Lastly, the fcf_aml_seg_reassignment job is similar, except that it is used to reassess customer behavior and reassign customers to another segment, if necessary.   It’s important to mention that you might have to adjust the parameters of these jobs depending on your organization. Lets use the young_threshold parameter as an example. When there is insufficient behavioral information for a given customer, that customer cannot be assigned a segment from a segment group that is generated using behavioral features. Such customers are assigned to a special segment titled Unclassifiable Segment. The criteria for being assigned to the unclassifiable segment is specified via the parameter young_threshold. This parameter determines the minimum number of transactions that the customer needs to have to be eligible for a segment assignment. The default value is 10, but you might set the value differently depending on your data.   In addition, all the jobs produce a report in PDF format. The report contains information pertaining to the data that was used as well as the intermediate and final results during job execution. These reports can be found in the SAS Drive folder location at /SAS Content/Products/SAS Anti-Money  Laundering/ AnalyticStores/Job Reports.   To learn more about segmentation and SAS Anti-Money Laundering in general, please visit https://support.sas.com/en/software/sas-anti-money-laundering-support.html.     Find more articles from SAS Global Enablement and Learning here. ... View more

  SAS Anti-Money Laundering provides out-of-the-box analytics reports. These reports leverage SAS Visual Analytics to produce and display the reports. The purpose of this post is to show you how to configure these reports on the Viya 4 platform.   You must execute three SAS jobs in SAS Job Execution Web Application to configure all the analytics reports. Typically, the URL to access SAS Job Execution includes the name of the deployment domain, and then SASJobExecution with an ending slash (i.e. http://server/SASJobExecution/)   After you’ve signed into SAS Job Execution as an administrator user, in the Content panel on the left, you’ll navigate to SAS Content, Products, SAS Anti-Money Laundering, and then Jobs. Under Jobs, you see a job for each of the analytics report categories, alert events, cases, and SARs.   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   It’s important to mention that data must be loaded into your CAS server in order to see the reports after you run these jobs.   For instance, to configure the alerts events analytics report, right click fcf_va_alerts_events_ETL, and select Submit job.     After the job runs successfully, you can verify the alerts events report was created by navigating to SAS Visual Analytics.   On the application bar, click the Show list of application icon, and under the Analytics Life Cycle section, right-click Explore and Visualize, and then Open link in new tab.   In Visual Analytics, navigate to SAS Content, Products, SAS Anti-Money Laundering, Management Reports, and then Alert Event Reports. Notice the four different reports.     If you click on the Active Alerts Aging reports, you’ll see something like the following:     You’ll repeat these steps for the fcf_va_case_ETL job and the fcf_va_SARs_ETL job. It’s important to mention that if you receive an error when running fcf_va_SARs_ETL job, it could be because you don’t have any SARs in the system. This is a bug, and a workaround is to create a manual case from the Homepage, and then from this case, create a SAR report.   After each job runs successfully, you can schedule the jobs in SAS Environment Manager to run at required intervals to refresh the report data at intervals that suit your business needs. To learn more about how to schedule these jobs and SAS Anti-Money Laundering in general, please https://support.sas.com/en/software/sas-anti-money-laundering-support.html .     Find more articles from SAS Global Enablement and Learning here. ... View more

  SAS Anti-Money Laundering enables users to perform different types of searches as part of their investigation. In this blog, I give a brief description and provide examples of two of these types of searches, form search and advanced search.   A form search, or a targeted search, enables you to search for objects of a specific type directly from the home page. You could use this type of search if you were looking for all of the closed cases in the system or if you were searching for a particular account. Let’s take a look at an example.   Let's say I want to search for a particular account. To do this, I use the form search on the Home page. First, I click Home on the menu bar, and then expand Advanced Search.   I select Accounts because I am looking for a particular account. In the Account Number field, I enter "01-0000229161" (note the quotations), then click Search.   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   In the Detail view, I can double-click Robin Hunt's account to view additional details about the account.     If you have the need to create a more complex search, without having knowledge of how to construct a complex query, you can perform an advanced search . An advanced search enables you to narrow your search parameters to achieve even more targeted results.   Suppose I want to search for a list of customers with Donald as the first name and any last name starting with the letter D.   On the Home page, I click the Advanced Search icon in the search field.     Then, for Select an object type, I select Customer. For Select a category, I select Customer First Name. For Operator, I select Phrase. To add an additional query parameter, I click the plus icon. I change the category to Customer Last Name, and for the operator, I select Contains all. In the Value field, I enter D and click the wildcard modifier *. Notice that the text area underneath shows the generated query text.     Lastly, I click Search. I see 15 results.     Knowing how to search the database is such a crucial part of the investigation process. To learn more about searching and SAS Anti-Money Laundering in general, please visit https://support.sas.com/en/software/sas-anti-money-laundering-support.html. ... View more

  SAS Anti-Money Laundering enables users to perform searches to discover information in support of their investigation efforts. In this blog, I give a brief description of one type of search that you can perform in the solution, a global search, and I include some examples within the solution.   A global search enables you to search for any object within the data repository. It’s important to mention that search terms are case-insensitive.   Let’s look at some examples that you might use when performing a global search.   The search terms “Jack and Jill” return all indexed data containing the phrase Jack and Jill, in that order (note the quotation marks).   The search terms Jack AND Jill return all indexed data containing the words Jack and Jill. It is important to note that the operator must be in all capital letters.   The search terms Jack Jill return all indexed data containing the word Jack or Jill, or data that contains both Jack and Jill.   The search terms Jack NOT Jill return all indexed data containing the word Jack that does not also contain the word Jill.   The search terms "Jack Jill"~3 return all indexed data containing the words Jack and Jill within three words of each other, in any order.   The question mark is a single-character wildcard. The search term ?ill returns all indexed data containing the words Jill, hill, will, and so on. It does not return data containing ill or thrill.   The tilde enables you to perform a fuzzy search. A fuzzy search finds objects that contain terms close to your search terms without matching exactly (for example, when words stored in the data repository are misspelled or mistyped). The example here, the~, returns all indexed data containing the common misspelling teh.   The search terms first_name: Jack return all indexed data containing the word Jack in the field first_name.   Lastly, the asterisk is a multiple-character wildcard, including zero characters. The search term t*ill returns all indexed data containing the words till, thrill, trill, treadmill, and so on.   It’s important to mention that you cannot start a search using a leading wildcard (for example, *ill). However, searching for * with no additional search terms returns all indexed data. Let’s take a look at this:   To access global search, on the menu bar, click Search. In the Search field, I enter the wildcard character, which is an asterisk, and then press Enter. This will return all objects in the system. The filters pane shows the various entities that exist.     Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   Next, let's perform a global search on the customer Robin Hunt. In the screenshot below, notice that in the Search field, I entered "Robin Hunt". The quotation marks ensure that results with the string Robin Hunt, in that exact order, are returned. After I press enter, I see that there are three results. An account, a customer, and a household - all associated with Robin Hunt.     I can click on Robin Hunt's household to see additional information in the Object Inspector pane on the right. To see even more details, I can double-click Robin Hunt's household.   Knowing how to search the database is such an important part of the investigation process. To learn more about searching and SAS Anti-Money Laundering in general, please visit https://support.sas.com/en/software/sas-anti-money-laundering-support.html.     Find more articles from SAS Global Enablement and Learning here. ... View more

  If you’ve used our Anti-Money Laundering solution over the years, you may have noticed that the concept of an alert, as well as the terminology surrounding an alert, has changed. In this post, I’d like to discuss what an alert represents in our AML solution on the Viya 4 platform and describe the important associated terminology, including how alerts are created.   At a high level, an alert is an event that is unusual and requires further attention from an analyst.   An analyst investigates two types of alerts in AML, transaction monitoring and watchlist monitoring. Transaction monitoring alerts are created when customer behavior indicates potential money laundering or terrorist financing, and watchlist monitoring alerts are generated if a potential match is detected between one of the financial institution’s customers and data provided from consolidated watchlist vendors. These alerts indicate potential sanctions targets.   Before I explain how these alerts are created, I need to define a couple more important concepts. First of which is a scenario.   Financial institutions must comply with anti-money laundering, or AML, regulations. To help financial institutions implement these regulations, SAS Anti-Money Laundering offers predefined scenarios, or rules.   These scenarios contain the logic to help financial institutions detect and report suspicious activity to be in compliance with AML laws and regulations. The scenarios that come out of the box can be used as guidelines, and custom scenarios can be created to meet your organization’s specific needs.   In SAS Anti-Money Laundering, these scenarios are run as part of a flow. A flow is the top-level container that consists of scenarios, the data sources to be evaluated by the scenarios for the behavior of interest, and can also include scorecards, which enable you to perform final processing using the events that are generated by the scenarios in the flow.   The alert generation process, or AGP, executes the flows in the system. A flow can consist of multiple scenarios. When the AGP runs, the system processes all of the logic contained in the scenarios.   Then the system includes all the scenario-fired events, by entity, in an alerting event.   Alerting events are then routed to the Visual Investigator alert service, where one alert is created per entity.    Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   I just described how alerting events can be generated by executing flows within scenario administrator, but it’s important to mention that alerts can be generated by other methods. For example, alerting events can be generated by a third-party alerting system and ingested in the solution using an alert API. In addition, you can manually create an alert in the end user interface.   No matter what the method of creation, the alert service ultimately creates one alert per entity.   Regardless whether you’re an end user or an administrator, it’s important to understand the concept of an alert. To view more information about alerts and our SAS Anti-Money Laundering solution in general, please visit https://support.sas.com/en/software/sas-anti-money-laundering-support.html.     Find more articles from SAS Global Enablement and Learning here. ... View more

  The purpose of this post is to give a high-level overview of how to perform an enhanced due diligence, or EDD, review in SAS Customer Due Diligence.   The customer review process starts with an alert for a high-risk customer.   Investigators analyze the alert and the customer’s data to make a final decision about the customer. For example, the investigator can decide to demarket the customer or modify the risk rating of the customer. If the investigator determines that more information is needed to make this decision, an enhanced due diligence, or EDD, Review is opened.   To create an EDD review, on the toolbar of an opened alert, click Disposition and then select Open EDD review.   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   Then, you fill out the required information, and click OK to open the review.     On the Report Details tab of the review, you’ll see the EDD Report. The EDD Report is used to collect and record relevant customer information so that a decision can be made on how to handle the customer. The report, which is a major part of the customer review, consists of multiple check boxes to indicate which of the questions needs to be answered during the review.   When a question, or report item, is selected, such as a source of funds review, the Completed check box is activated. After the CDD analyst completes the source of funds review, or whichever action items they deemed necessary for the review, the CDD analyst then selects the Completed box to indicate that this stage of the review is finished. After the Completed box is selected, the corresponding Comments field is activated. A comment is required to complete the enhanced due diligence questionnaire.     Sometimes, you’ll need additional background information to make your final decision about whether to exit or maintain a customer. SAS Customer Due Diligence provides an easy way to organize this additional review process through its Enhanced Due Diligence review.  To learn how to create an EDD review from the interface and to learn more about the solution in general, please view SAS Customer Due Diligence | SAS Support.     Find more articles from SAS Global Enablement and Learning here. ... View more

  The purpose of this post is to summarize the risk ranking process overall, and to show how to run the customer risk ranking, or CRR, flow in the SAS Customer Due Diligence interface. The CRR flow is what ultimately creates alerts in the system for analysts to review and assess the customer relationship.   The customer risk ranking process can be summarized in five main steps.   First, the alert generation process, or AGP, runs the customer risk ranking, or CRR, flow. The CRR flow contains scenarios that process customer data to calculate risk scores. This risk rating is based on a scorecard, which contains attributes pertaining to citizenship, residence, products, and occupation that are risk rated and scored themselves. For example, a customer receives a score of 60 for being a Dutch citizen and 20 for residing in the United States. The attributes and scores are stored in the CRR Lookup table. CRR Lookup is an entity that contains scores for the various attributes that make up a customer’s customer due diligence profile.   After the customer data is processed and risk scores are calculated, the system generates alerts for the high-risk customers. These alerts are made available in the customer due diligence user interface.   To run this flow and create alerts, first, navigate to SAS® Environment Manager, which comes out-of-the-box with a SAS Viya install. Then, on the navigation bar on the left, click Jobs and Flows and navigate to the Scheduling tab. Right-click the cdd_prep_vi_daily job, and select Execute.     Alerts that are created from the AGP show on the Alerts page, in the High-Risk Customers strategy.     Next, the analyst assesses the alerts that were created from the AGP and specifies a decision, or disposition, for that alert. For example, based on the alert review, the analyst could decide to modify the customer’s rating to medium.   If required, further investigation and background checks, or enhanced due diligence, is conducted to validate the score and to get more information about the customer.   Lastly, the results of the investigation are integrated in the next customer risk ranking process to calculate new risk scores.   SAS® Customer Due Diligence enables you to assess customer relationships and establish expectations about customer behavior. To view more information about the customer risk ranking process, and the SAS Customer Due Diligence solution overall, visit https://support.sas.com/en/software/customer-due-diligence-support.html.     Find more articles from SAS Global Enablement and Learning here. ... View more

The purpose of this post is to give you an overview of the watchlist monitoring feature of SAS Anti-Money Laundering.   SAS Anti-Money Laundering enables institutions to meet regulations that concern sanctions monitoring. This is accomplished by providing code modules to read in and process data from consolidated watch list vendors. It’s important to note that SAS Anti-Money Laundering does not provide the third-party watch list data itself. This solution provides the tools to read and process the watch list data only. More specifically, SAS Anti-Money Laundering provides the ETL (or extract, transform, and load) code for the World-Check, Dow Jones, Accuity, and 314(a) watch lists. After the watch list data is stored in the solution, it is then compared against customer data in the financial system to detect customers, individuals, or organizations with potential sanctions targets.   The watch list monitoring process consists of three jobs: the fcf_aml_load_watchlist job, the fcf_aml_set_core_matchcodes job, and the fcf_aml_prep_matchcode job. You can access and run these jobs in SAS Job Execution, which comes out-of-the-box with a SAS Viya install.   After you’re in SAS Job Execution, in the left panel under SAS Content, expand Products, SAS Anti-Money Laundering, and then jobs.     Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   First, you run the fcf_aml_load_watchlist job. To do this, right-click the fcf_aml_load_watchlist job, and select Submit job.     This job reads in watch list data from the chosen third-party vendor and performs processing on the data before storing it in the amlwatchlist schema. This job also produces match codes for the watch list data. Match codes are encoded representations of input character variables that are used to match data in a non-exact way. Each match code encapsulates certain information about the input value or values from which it is derived. If two input strings generate the same match code, then those two strings are intended to represent the same entity, if the match sensitivity level applied during match code creating is the same upon processing.   Next, you run the fcf_aml_set_core_matchcodes job, by right-clicking and selecting Submit job, which generates the match codes for the client data. These are stored in the core schema.   Lastly, you run the fcf_aml_prep_matchcode job, again by right-clicking and selecting Submit job, which compares the watch list match codes and the client match codes.  After the comparison is complete, any matches are stored in the amlprep schema.   Two out-of-the box scenario flows have already been created to produce alerts on the watch list prep data generated by the fcf_aml_prep_matchcode job.   SAS Anti-Money Laundering enables you to meet regulations, including regulations that concern sanctions monitoring. To view more information about this optional watch list feature and our SAS Anti-Money Laundering solution in general, please visit https://support.sas.com/en/software/sas-anti-money-laundering-support.html.     Find more articles from SAS Global Enablement and Learning here. ... View more

The purpose of this blog is to provide a summary of the SAR90 case that’s automatically created as part of the SAS Anti-Money Laundering case investigation process.   In SAS Anti-Money Laundering, a case is a collection of alerts, entities, and supporting documentation into one object so that you can determine whether suspicious behavior exists. A case has a predefined workflow, which is initiated when the case is created. Workflows consist of tasks assigned to users or groups, and they automatically move to the next task after the current task is complete.   In the case workflow, the AML investigator is responsible for completing the case investigation and for indicating whether a SAR, or a suspicious activity report, is needed. The AML investigator is also responsible for creating this regulatory report. If a case has a report associated with it, then the case first gets passed to the AML manager for review before it can be closed. After the case is closed, a random selection of cases is passed to quality assurance for review.   In addition, SAS Anti-Money Laundering automatically creates a SAR90 follow-up case that enables you to review and report continuing suspicious activity. Institutions typically start a continuing activity review case 90 days after a SAR case has been filed and, if appropriate, file a continuing activity SAR within 120 days of the original SAR filing date. This practice enables law enforcement to become aware of the continuing nature of previously reported activity, and it also enables the institution to determine whether an internal policy action might be appropriate.   After a SAR is filed and is accepted, the system creates a SAR90 case that has a status of Suspended by default. This SAR90 case includes all subjects from the parent, or original case, and the owner of this new case is set to the same as the owner of the parent case as well. All the SAR90 case subject’s alerts are dispositioned to the SAR90 queue. This new SAR90 case is automatically activated after 90 days. If you plan on working on the SAR90 case prior to the 90 days, you can activate the SAR90 case. In addition, if a SAR90 case is about to expire, you can reset the timer to extend it another 90 days.       SAS Anti-Money Laundering makes it very simple to continually review your customers, including the ones that already have a SAR filed. To view more information about our SAS Anti-Money Laundering solution, please visit   https://support.sas.com/en/software/sas-anti-money-laundering-support.html. ... View more