This is the second part of a series that discusses regulatory reporting related to financial crimes in the United States.   Part 1, Currency Transaction Reports and Designation of Exempt Persons Part 2, Suspicious Activity Reports   In a previous post, we learned that the Annunzio-Wylie Anti-Money Laundering Act in 1992 required financial institutions report activity that aggregates at least $5,000 by filing the Suspicious Activity Report.   When filing a Suspicious Activity Report, there are a multitude of data points that are being sent to FinCEN. The first step is identifying the type of filing.   Initial report This is the most common option and represents new suspicious activity. Correct/Amend prior report This option is available if a mistake was made in a previous report. Continuing activity report This option is for when this report involves suspicious activity that was previously reported but has continued. Reports should be filed at least every 90 days on continuing suspicious activity. You can read about continuing activity in this post Joint report Select this option if two financial institutions discover the activity together and are both being used for the activity. Prior report Document Control Number/BSA Identifier If b or c are checked, enter the identifier of previous report.   Next, there is an option to upload a .csv file as an attachment. This file would be used to document transaction records.   This was an amazing improvement in the reporting process. Can you imagine typing out "On 1/7/2023, the customer deposited $9,000 in cash to account 1 at branch North. On 1/9/2023, the customer deposited $9,000 in cash to account 2 at branch North. On 1/11/2023, the customer deposited $9,000 in cash to account 1 at branch South. On 1/12/2023, the customer deposited $9,000 in cash to account 2 at branch West." for several months of activity? I will tell you; it was a pain. I got to know how to concatenate in Excel really well!   In the Suspicious Activity Report, there are five parts that break down the Who, What, When, and Where.   Part I - Subject Information   In this section, you identify every known subject involved in the suspicious activity. This includes First, Middle and Last name of the person (or legal name of a business), Gender, Alternate names   Occupation (or type of business), Tax Identification Number, Date of Birth, Phone number, Email address, etc.   Part II - Suspicious Activity Information   In this section, you identify the total amount of the activity as well as the date range of the transactions. You select from a list of activity types to identify what you suspect is going on. For example, Structuring, Terrorist Financing, Fraud, Money Laundering etc.   Part III - Information about Financial Institution Where Activity Occurred   This section is specifically for the location of the activity. For example, a branch, an ATM, online, multiple locations as well as the address of each.   Part IV – Filing Institution Contact Information   This section records the financial institution, holding company, agency, or other entity that is filing the report. It includes the name of the financial institution, the TIN, who the regulator is, what type of financial institution it is, etc. This section also includes fields to identify if law enforcement was contacted, what agency, and the contacts name and number.   Part V - Narrative   This section is where you become a storyteller. This part is critical to someone reading it, so they understand the nature and circumstances of the suspicious activity. It is important to use full, complete sentences and no acronyms.   SAS Anti-Money Laundering makes completing and filing regulatory reports incredibly simple by storing all the relevant data for the investigator. To learn how to use SAS Anti-Money Laundering, you can take one of these e-learning courses   Course: Using SAS® Anti-Money Laundering in SAS® Viya Course: Administering SAS® Anti-Money Laundering in SAS® Viya®   For more information about the SAS Anti-Money Laundering solution, 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

At the most basic level, regulatory reporting is the process of collecting and submitting information to regulatory authorities. For the purposes of this series, we will focus on regulatory reports related to financial crimes in the United States, required by Financial Crimes Enforcement Network (FinCEN).   Remember, in the previous post Anti-Money Laundering: The Basics, we learned that   The Bank Secrecy Act in 1970 required banks to report cash transactions over $10,000 with the Currency Transaction Report. The Annunzio-Wylie Anti-Money Laundering Act in 1992 required a standard Suspicious Activity Report to be used to report activity that totals at least $5,000   Over the years, US regulations were expanded to incorporate all “financial institutions” which include banks, casinos and card clubs, money services businesses (MSBs), brokers or dealers in securities, mutual funds, insurance companies, futures commission merchants and introducing brokers in commodities, residential mortgage lenders and originators.   Starting July 1, 2012, these regulatory reports have been required to be filed electronically. FinCEN developed requirements for the type of file that must be submitted, the data that must be in the file and the layout of that data. Financial institutions can electronically submit reports through e-filing, or they can sign into the BSA e-filing system and manually complete the steps for submitting a report. Whether you are manually filing via FinCEN’s website or using SAS Anti-Money Laundering, the required fields are marked with an asterisk.   When I started in Anti-Money-Laundering, we were using PDF files and faxing them to FinCEN! We kept the fax confirmations in the paper files we kept with all of our investigation notes. File cabinet, after file cabinet lining the walls of the office.   Let’s start by looking at the Currency Transaction Report. The first step is identifying if the report amends a prior report, includes multiple persons or multiple transactions. The report is broken down into three parts.   Part I - Person(s) Involved in Transaction(s)   Section A – Person(s) on Whose Behalf Transaction(s) Is Conducted   This would be the information of the account holder where the transaction took place. This includes First, Middle and Last name of the person (or legal name of a business), Tax Identification Number, Date of Birth, Address, Identification, etc.   Section B - Individual(s) Conducting Transaction(s)   If the transaction was completed by someone other than the account holder, this would include the First, Middle and Last name of the person (or legal name of a business), Tax Identification Number, Date of Birth, Address, Identification, etc.   **There is a Part I completed for every transaction that occurred on a single day.   Part II - Amount and Type of Transaction(s).   This would include the total cash in and cash out as well as the amount of any foreign currency. There are check boxes for the type of activity, including wire transfers, currency exchanges, withdrawals, etc.   Part III - Financial Institution Where Transaction(s) Takes Place   This would include the name of the financial institution, the address, EIN, and routing number. IT would also have the name, title, and phone number of the person preparing the form.   As you can imagine, the requirement to keep up with the CTR requirement can be burdensome for a bank, especially for customers that have legitimate business reasons for large cash transactions. To assist, FinCEN does allow banks to "exempt" customers that meet certain requirements, for example other banks, government agency/government authority, publicly listed companies, etc. Banks are the only financial institution that are allowed to "exempt" customers from the Currency Transaction Reporting requirement and for every customer the bank wants to exempt, they must file a Designation of Exempt Person report.   The Designation of Exempt Person (DOEP) has four parts   Part I – Filing information   Here you indicate if this is: an Initial designation, Exemption amended or Exemption revoked and the effective date of the exemption. Any transaction past this date is not required to have a CTR filed.   Part II - Exempt Person Information   In this section, you identify the customer information which includes First, Middle and Last name of the person (or legal name of a business), Gender, Alternate names, Occupation (or type of business), Tax Identification Number, Date of Birth, Phone number, Email address, etc. As well as the type of exemption.   Part III - Filer Information   This section records the financial institution, holding company, agency, or other entity that is filing the report. It includes the name of the financial institution, the TIN, and who the regulator is.   Part IV   This section contains the name, title phone number and signature of the person who authorized the exemption.   With the newest release of SAS Anti-Money Laundering, LTS 2024.09 (November 2024), the CTR is available as a pre-configured regulatory report. It is integrated with the AML Case, associated workflows, and e-filing functionality (similar to the Suspicious Activity Report).   Check out the next post in the series, Regulatory Reports in SAS Anti-Money Laundering: Part 2   Find more articles from SAS Global Enablement and Learning here. ... View more

In the previous post, Scenarios in SAS Visual Investigator, you learned about the three different kinds of scenarios. Let's look in more depth at the Lookback options we have when using the Aggregation Scenario.   When using an aggregation scenario, we have to identify what dates to include in our aggregation. You know if you have ever bought a paper calendar, there are options for viewing by a day, a week or a month. I’m a weekly girl. I like to see my whole week at a glance. But some people prefer to see the whole month at once. And I even have a crazy friend who uses a daily calendar!   Well, the lookback is liking picking your calendar view. What timeframe are you viewing? That is the Lookback Unit, day, week or month, etc. Next you need to decide how many Lookback Units you are grouping together.   Example 1: Let’s say you want to monitor for a Currency Transaction Report. Banks are required to file if any single person deposits or withdraws over $10,000 cash in a single day. You would create a scenario with Day for the Lookback Unit and 1 for the Lookback, to aggregate a single day’s cash transactions.   Example 2: Let’s say you want to monitor for structuring. Typically, structuring occurs when someone wants to avoid a Currency Transaction Report, so there would be multiple cash transactions just under $10,000 within a few days. You would create a scenario with Day for the Lookback Unit and 7 for the Lookback, to aggregate seven day’s cash transactions. *In this example, you would also want to include a count of transactions in your rule, so you aren’t also catching those that had a single transaction over $10,000 and did have a CTR filed.   Now there is another option to use with the Lookback and it’s called Offset. By default, the scenario aggregation starts at the last day of the data. Let’s say our data is for the first month of the year, 1/1/2024 through 1/31/2024.   Example 1: The scenario is only for a single day, so it would aggregate 1/31/2024.   Example 2: The scenario would start at 1/31/2024 and go back 7 days, to 01/25/2024, and aggregate the transactions for those days.   The offset changes the last date of the data by the Lookback value to determine the date at which to start aggregation. So, if our data ends with 1/31/2024, we can aggregate an earlier time period by adjusting the offset.   Example 2: If we add an offset of 1, the scenario will start at 1/24/2024 and go back 7 days, to 01/18/2024, and aggregate the transactions for those days. If we add an offset of 2, the scenario will start at 1/17/2024 and go back 7 days, to 01/11/2024.    Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   Using an offset in this way is useful for comparing aggregations. For example, using the different offsets, you could write a rule to compare the weekly amounts and see if there is a steady increase or decrease in activity.   To learn more about writing scenarios in SAS Visual Investigator or using the out of the box scenarios in SAS Anti-Money Laundering, the courses Building an Interface with SAS® Visual Investigator and Administering SAS® Anti-Money Laundering in SAS® Viya® are available as eLearning.     Find more articles from SAS Global Enablement and Learning here. ... View more

In the previous post, What is an Alert in SAS Anti Money Laundering?, you learned that SAS Visual Investigator scenarios, or rules, contain the logic for detecting suspicious activity. Using SAS Visual Investigator, you can create three different types of scenarios.   Record-level scenarios look at individual transactions for all records in the data. You would use a record-level scenario to detect a single cash transaction over $10,000 for a currency transaction report. Aggregation scenarios look at data at an aggregated level, by one or more columns in the data. You could use an aggregation scenario to detect aggregated cash withdrawals in excess of $10,000 over a period of five days. DATA-step scenarios enable you to have more flexibility and is dependent on SAS DATA step code. You would use a DATA-step scenario to detect a deposit made the same day as an ATM withdrawal in another state.   The user-friendly interface makes it easy for a scenario designer to identify the required fields. The screen is broken out into several tabs with dropdown fields. The tabs displayed are dependent on the type of scenario you are creating. Regardless of the type of scenario some of the basic information you will need to select includes:   Name: A scenario name must be unique within the flow   Active: This check box indicates whether the scenario is active in the flow. You can deactivate scenarios you don’t want to include when the flow is run.   Actionable Entity: This is the entity for which you want to gather suspicious activity, and then review via an alert. This entity correlates to a person that you can investigate, for example a bank customer or an insurance poly holder.   Scenario-Fired Entity: This is the entity that you want to surveil for suspicious activity. For example, a bank account or an insurance claim.   Include Records: This check box specifies whether to include records in the scenario context with each alerting event that a flow generates.   *If you enable, you can also choose to replicate the scenario contact records. This means, these records will be displayed to the end user to review as part of their investigation.   Include These Records: You can select one of the below options   All contributing records: For the scenario-fired entity object, includes all the records that exist within the time frame that is defined for the scenario. This includes both the records that caused the scenario to fire and those that did not. All contributing records (flag triggering records): For the scenario-fired entity object, includes all the records that exist within the time frame that is defined for the scenario. Only triggering records: For the scenario-fired entity object, includes only the records that triggered the scenario-fired event.   Parameters: Parameters enable you to manage the value that is assigned to one or more scenario fields using an object that holds a value, as opposed to an actual value. Each parameter requires an ID, a Description, a Type and a Default Value.   Depending on your monitoring needs, you may need to transform the data with Expressions and/or Aggregations.   Expressions: Using data source columns, you can create a mathematical expression   Aggregations: Using a or a scenario expression, you can define a metric (such as sum, count, or mean) with a lookback unit to define if you are aggregating by day, month, or year. There is also an option to define an Offset to the Lookback value, which will be described in more detail in a future post, Using a Lookback in Scenarios: Lookback Basics.     Once you have all the information for detection selected, you will need to define a rule to categorize the outcome of the scenario.   the conditions that must be matched in the source data to generate a scenario-fired event a score, value, and message to scenario-fired events a recommended queue in which to route alerting events   To learn more about writing scenarios in SAS Visual Investigator or using the out of the box scenarios in SAS Anti-Money Laundering, the courses Building an Interface with SAS® Visual Investigator and Administering SAS® Anti-Money Laundering in SAS® Viya® are available as eLearning.     Find more articles from SAS Global Enablement and Learning here. ... View more

In 2021, Congress passed the Corporate Transparency Act (CTA), which created a new requirement for companies to report beneficial ownership information. This is part of the U.S. government’s efforts to make it harder for bad actors to hide or benefit from their ill-gotten gains through shell companies or other opaque ownership structures.   Beneficial ownership information (BOI) refers to identifying information about the individuals who directly or indirectly own or control a company.   The CTA calls for a centralized database to house the BOI, which is maintained by FinCEN. Filing is free of charge and is a one-time requirement with a deadline of January 1, 2025.   How do I know if my company needs to report BOI?   Companies are only required to report BOI if they meet the definition of a “reporting company” and do not qualify for an exemption. There are two types of reporting companies: Domestic Company: A corporation, a Limited Liability Company (LLC), Other entity created by filing a document with a Secretary of State Foreign Company: A corporation, a Limited Liability Company (LLC), Other entity formed under the law of a foreign country that is registered to do business in the United States by the filing of a document with a Secretary of State Companies that are not required to report BOI include: Non-Reporting Company: Entities that are not created by filing with a secretary of state, for example, sole proprietorships and certain trusts. Exempt Company: Securities reporting issuer, Governmental authority, Bank, Credit union, Depository institution holding company, Money services business, Broker or dealer in securities, Securities exchange or clearing agency, Other Exchange Act registered entity, Investment company or investment adviser, Venture capital fund adviser, Insurance company, State-licensed insurance producer, Commodity Exchange Act registered entity, Accounting firm, Public utility, Financial market utility, Pooled investment vehicle, Tax-exempt entity, Entity assisting a tax-exempt entity, Large operating company, Subsidiary of certain exempt entities, Inactive entity Intentionally failing to report BOI may results in civil or criminal penalties. Civil penalties include up to $500 for each day that the violation continues. Criminal penalties include imprisonment for up to two years and/or a fine of up to $10,000. Senior officers of an entity that fails to file a required BOI report may be held accountable for that failure.   Who is a beneficial owner of my company?   A beneficial owner is any individual who, directly or indirectly exercises substantial control or owns or controls at least 25 percent of the ownership interests. There is no maximum number of beneficial owners who must be reported. Any individual who owns or controls at least 25% of the Ownership Interests. This can include:   Equity, Stock or Voting Rights Capital or Profit Interest Convertible Instruments Option or Privilege Any individual who exercises Substantial Control over the company. This can include:   Senior Officer Appointment or Removal Authority Important Decision-Maker Any other form of substantial control   Do I have to report company applicants?   Companies registered prior to January 1, 2024, are not required to register company applicants. Companies registered on or after January 1, 2024, must report company applicants. A company applicant can be up to 2 individuals.   The individual who first filed the document with the secretary of state The individual who is primarily responsible for the document What information is reported?   BOI reports require specific information about a company, its beneficial owners, and applicants.   Information required for a reporting company:   Legal Name Any trade name or DBA Complete US address State, Tribal, or foreign jurisdiction of formation Internal Revenue Service (IRS) Taxpayer Identification Number (TIN) If a foreign reporting company has not been issued a TIN, report a tax identification number issued by a foreign jurisdiction and the name of such jurisdiction. State or Tribal jurisdiction of first registration (foreign reporting companies only)   Information required for each beneficial owner and applicant:   Legal name Date of birth Complete current address Unique identifying number and issuing jurisdiction from, and image of, one of the following non-expired documents: US Passport State driver’s license Identification document issued by a state, local government, or tribe If an individual does not have any of the previous documents, a foreign passport   When do I have to file?   Companies registered prior to January 1, 2024, are required to file by January 1, 2025. Companies registered on or after January 1, 2024, have 90 calendar days after receiving notice of creation or registration to file its initial BOI report.   How do I file?   FinCEN has a secure filing system with complete instructions located at www.fincen.gov/boi.   How do I change my information?   Corrected reports are required when previously reported information was inaccurate when filed. Due within 30 calendar days of company becoming aware of inaccuracy. This includes any inaccuracy regarding the company, beneficial owners, or applicants.   Updated reports are required when there is a change to previously reported information about the company or its beneficial owners and are due within 30 days of the change. Examples of changes that would require an updated BOI report:   Any change of information for the company, for example registering a new DBA. A change in beneficial owners or the death of a beneficial owner. Any change to a beneficial owner’s name, address, or unique identifying number provided in a BOI report. *This includes a new identifying document that expires and is renewed. For more information about the Beneficial Owner reporting requirements, see Beneficial Ownership Information Reporting | FinCEN.gov ... View more

Keeping information secure is just one of the challenges law enforcement officers have to deal with. Even amongst the same department, only certain people should know certain things. SAS Law Enforcement Intelligence has the functionality to limit access to sensitive records to approved users only.   A Confidential Information is a person who works undercover for law enforcement to gather information about criminal activities, and could be criminals themselves, hired to work undercover in exchange for leniency or exoneration.   There are two different data objects involved in creating a confidential informant, an Informant Request and an Informant Profile. In our example below, we have three different users, Officer Mallory, Sergeant Smith and Officer Canning.   Officer Mallory thinks James Bulgar has a lot of information about crime in the neighborhood and has convinced him to be an informant, so he creates an Informant Request. In the request, he completes all the available information; first and last name, date of birth, sex, aliases, etc. Once complete, he submits the Informant Request to his supervisor Sergeant Smith for review.  Sergeant Smith reviews the information in the Informant Request and determines if the informant should be approved or denied. If approved, she submits the Informant Request to Officer Canning for verification. Officer Canning's job is to ensure that James Bulgar is not already in the system as a current or previous informant, so the database is kept tidy and up to date. Officer Canning verifies there is no conflict, and the Information Request returns to Sergeant Smith. Now that Sergeant Smith knows there is no conflict, she approves the Informant Request, which creates a new Informant Profile assigned to Officer Mallory. Officer Mallory completes the information in the Informant profile. (Using the autofill toolbar, we can populate information from the Informant Request data object directly into the Information Profile). She then submits the Information Profile to his supervisor Sergeant Smith for approval.  Sergeant Smith, approves the profile, which makes it active.   Only the officer assigned to the Informant Request and an Informant Profile, their manager and members of the conflict checking group are able to view the records. If I'm signed in as Officer Valorie, for example, and perform a search for James Bulgar, neither the Informant Request nor the Informant Profile would be in the search results.     Find more articles from SAS Global Enablement and Learning here. ... View more

In SAS Visual Investigator, workflows are used to manage the investigation process. Workflows consist of a series of tasks that directly proceed to the next task in the sequence as each is completed.   For example, Acme Insurance might want a workflow such that, when an investigation is created, the workflow automatically starts and a new task for Investigators is created. Acme insurance can also configure the workflow so that the investigation is passed on to a manager or closed depending on what the investigator deems appropriate.   Workflows consist of five types of elements: events, gateways, notifications, services, and tasks. (these are grouped in the interface according to how they are used). Workflow templates are built by adding these elements to the workflow editor.   There are two types of events: Start and End. A Start event must be the first element in the workflow. It is automatically added to the editor when a new workflow template is created. You can have only one Start event in each workflow. The End event is the last element in the workflow. When the workflow reaches the End event, the workflow terminates. Each workflow must have a Start event and an End event.  Gateways enable the workflow to split. There are two types of gateways: parallel gateways and exclusive gateways. Parallel gateways enable the flow to take multiple paths and run concurrently. Exclusive gateways direct the process to only one path. The notification element can send an email to specified users or groups. The subject and body of the message can be configured, and either can contain a workflow variable. Entity links can also be inserted into the message text. When the workflow proceeds through the email notification element, the email is sent. Services provide a way to manipulate the workflow process behind the scenes, without any user completing a task. Two types of services can be included in workflow templates. REST services enable communication with external systems or other SAS Visual Investigator components using a URL. The URL is called, and the workflow is updated using this element. REST services can update workflow variables but not entity fields. Write services, in contrast, enable both workflow variables and entity fields to be updated. They are similar to user tasks in this regard but require no action to be taken by a user. They can be used to auto-update entities. There are two types of tasks: user tasks and script tasks. User tasks require direct action from a user in order to advance the process through the flow. Tasks can be specifically restricted by user type. For example, you might create an Approve Investigation task that is to be completed only by those with Manager status. Script tasks enable advanced scripting options to be used in the workflow. They can modify workflow variables and entities. You must be comfortable with JavaScript in order to use a script task. Lastly, sequence flows link workflow elements together. If a sequence flow is coming from an Exclusive Gateway node, then a condition property should be set so that the gateway can determine which path the flow should take.   The path a workflow takes is controlled by workflow variables. For example, an exclusive gateway uses the value of the variable to determine which path to take in the workflow. The two types of workflow variables are entity defined and user defined.   Entity-defined variables are based on internal entity fields and take their initial values from those fields. User-defined variables are created in the workflow and are global variables available to the entire workflow.   Workflows are fully customizable and can be as simple or as complex as an organization needs.     Find more articles from SAS Global Enablement and Learning here. ... View more

The purpose of this blog is to describe the different servicing methods in SAS Alert Triage.   Servicing is an approach of alert assignment that ensures the highest priority alerts are worked first. There are two methods of servicing, Priority servicing and Direct servicing.   First, let’s review how alerts are organized. Within a Domain, there are Triage Types that are used to group Queues. Triage Types and Queues both support servicing priorities, while only queues can have a routing priority associated with them. Servicing priorities allow the system to prioritize Triage Types and Queues when a user is servicing alerts while routing priorities, alongside routing rules, determine which queue a given alert will land in.   Initiating priority servicing is as simple as pressing the “Start priority servicing” button on either the homepage or the servicing page within SAS Alert Triage. Once the user has clicked this button the system will first identify all of the queues that user has access to. A user has access to a queue, and the alerts in that queue, if they are part of the user group that is associated with that queue.   Once the system has identified all of the queues that the user is associated with it will then identify the triage type with the highest servicing priority that one of these queues is associated with. After the triage type with the highest servicing priority has been identified the system then checks whether there are alerts in any of the queues grouped under that triage type, starting with the queue that has the highest servicing priority.   Once a queue has been identified that contains alerts the system picks the alert that appears at the top of that queue’s sort order. The sort order of each queue is administratively defined and can target any information on an alert. For instance, the alerts in a given queue could be sorted by the “date created” field to ensure that the newest alert is always appearing at the top of that queue’s sort order.   Direct servicing works in a similar fashion, just that the user is picking the triage type rather than the system. Selecting the triage type is very straightforward with users simply making a selection from a drop down list. Once a triage type has been selected the user can click the “Start direct servicing” button located alongside the drop down to initiate the servicing process. As with priority servicing, direct servicing can be initiated from either the homepage or the servicing page.   Let’s say we have two users, Mike and Jill, each with access to all Triage Types and Queues within a given Domain. Mike has both the “Direct Servicing” and “Priority Servicing” capabilities and can therefore work in either servicing pattern. Upon clicking “Start priority servicing” the system presents him with the alert appearing at the top of the high priority queue’s sort order. This is because the high priority queue is the queue with the highest queue servicing priority under the triage type with the triage type highest servicing priority, namely the credit card triage type.   Jill, on the other hand, only has the “Direct Servicing” capability, meaning that she will not see the “Start priority servicing” button. To begin servicing Jill must choose either the credit card or debit card from the drop down associated with the Direct servicing component. Having selected the debit card triage type, and pressing the “Start direct servicing” button, the system will present Jill with the alert appearing at the top of the high value queue’s sort order. This will be the case as the high value queue is the queue with the highest queue servicing priority under the debit card triage type that Jill chose   Alert servicing ensures that a user completes an alert before moving on to another alert. This is achieved by automatically locking the surfaced alert against the user. The user must then apply a disposition to the alert in order to release the lock on the alert. The intent behind enforcing the lock until the disposition is applied is to discourage users from simply releasing the lock on alerts that they might find difficult to work in hopes of being presented with an easier alert upon re-initiating servicing.   A major benefit of servicing is that users can also quickly move from one alert to the next as part of applying a disposition. As part of applying a disposition Jill or Mark can press the “Update & continue” button to have the disposition applied and the system pick out the next alert that they should be working, based on the servicing pattern they originally initiated. This ensures that users are fully utilized and the redundant clicks of re-initiating servicing from the homepage, or servicing page, are eliminated.   To view more information about SAS Alert Triage, please visit https://support.sas.com/en/software/sas-alert-triage-support.html ... View more

This blog is the last part of a three part series that discusses Anti-Money Laundering.   The Basics The Financial Industry Real Life Examples (this article!)   Reminders from Part 2   Financial Institutions are required to file a Currency Transaction Report, or CTR, for any cash transactions over $10,000. The practice of executing financial transactions in a manner as to avoid the CTR filing requirement is known as structuring. Financial Institutions are required to have an anti-money laundering to detect suspicious activity. Financial Institutes are required to file a Suspicious Activity Report, or SAR, for activity that appears unusual. Story 1   A restaurant owner structured cash deposits at two different banks, in an attempt to avoid the CTR filing requirement. Both banks filed SAR’s to report the unusual activity. What he didn’t know was that he had already been known to law enforcement for some time and his restaurant was known for dealing in stolen property and selling drugs. While numerous arrests were made, the restaurant owner was never charged.   Due to the SAR filings, prosecutors were able to detail 60 suspect transactions that he structured cash transactions to avoid currency transaction reports. This led to him being charged with structuring as well as to the forfeiture of the funds that had been seized during the investigation.   As part of a plea deal, he consented to the forfeiture of over $20,000, which the government seized during its investigation. He was also required to file amended tax returns as part of his plea, which resulted in more than $80,000 in taxes owed.   Story 2   A bank noticed the account of a pharmaceutical company had pattern of daily $9,800 currency deposits and filed a SAR. The bank then noticed the company’s deposit pattern changed to quantities of cashier’s checks in amounts under $10,000 and filed a second SAR. These reports led to an investigation that revealed the company was distributing pallet-load quantities of psuedoephedrine to a broker who was reselling the drug to large-scale methamphetemine manufacturing operations.   The company sold about 9,000 cases of pseudoephedrine, worth in excess of $5.6 million. Which is enough to produce over 9,000 pounds of methamphetamine with a wholesale value of over $54 million. Eleven individuals were convicted and more than $4 million in cash and property was seized. Story 3   A motor home dealer obtained loans from a bank, using trade-in motor homes as collateral. The dealer would then sell the used motor homes to individuals and fail to notify or repay the bank. Purchasers of the motor homes and RVs were told they would be mailed the title, which never happened because the banks held them. During an audit, the bank discovered that numerous motor homes pledged as collateral were no longer in the possession of the dealer, amounting to approximately $500,000 and filed a SAR. During the investigation, approximately $600,000 was seized from the dealer, including over $490,000 in currency seized from a home safe.   ... View more

This article is the second part of a three-part series that discusses Anti-Money Laundering. The Basics The Financial Industry (this article!) Real Life Examples   Remember in Part 1, the Bank Secrecy Act (BSA) and Money Laundering Control Act (MLCA) required financial institutions to report: cash transactions over $10,000 with the Currency Transaction Report (CTR) suspicious activity with the Criminal Referral Form, later replaced with the Suspicious Activity Report (SAR)   While previous regulations required financial institutions to establish recordkeeping and reporting requirements, it wasn’t until the USA PATRIOT ACT in 2001 that the regulations for financial institutions started piling up. An example of some of those new requirements are as follows: Four Pillars Section 352 defined the minimum requirements for an anti-money laundering program as:   the development of internal policies, procedures, and controls. designation of a compliance officer. an ongoing employee training program. an independent audit function to test programs.   Well yeah, if you are going to have an AML program, it should have someone in charge and be documented and tested. But this means purchasing software for monitoring transactions and funding a department of investigators to ensure the bank isn’t accidentally (or intentionally) allowing money laundering to occur. And by the way, if you aren’t monitoring well or your investigators aren’t reporting correctly, the bank can be fined and/or be closed. Uh oh. Customer Identification Program Section 326 requires financial institutions to establish procedures for account opening that include:   verifying the identity of any person seeking to open an account, maintaining records of the information used to verify the person's identity, including name, address, and other identifying information. determining whether the person appears on any lists of known or suspected terrorists or terrorist organizations. Can you even imagine opening an account anywhere without confirming your identity? I think I had to verify my identity to get the reward card at my grocery store! But in the “old days”, banks didn’t have any rules around verifying that a person was who they said they were. Information Sharing Section 314 permits financial institutions to share information, for the purposes of identifying and reporting activity that may be related to money laundering or terrorist financing, with:   another financial institution law enforcement So, if you think your bank is talking about you behind your back, they might be. SAR Disclosure Section 351 strengthened the confidentiality of the SAR by prohibiting a financial institution from disclosing to any person involved that the transaction was reported. And if I, as a banker, did happen to reveal to a long-time client that the bank filed an SAR on them, I could face a civil penalty up to $100,000, a criminal penalty up to $250,000 and up to 5-year imprisonment. (I do remember using that little tidbit as a footer in emails in a past career.) Financial institutions were originally what we knew as a banks or credit unions but with the passing of new regulations, came an expanded definition of financial institution. So now we are talking about not only banks, savings associations, credit unions, registered brokers and dealers in securities, futures commission merchants, and casinos but also insurance companies, loan or finance companies, automobile and other vehicle dealers, and persons involved in real estate closings and settlements. This is because ill-gotten gains have to be integrated back into the economy for the cycle to be complete.     ... View more

This post is the first part of a three part series that discusses Anti-Money Laundering.   The Basics (this article!) The Financial Industry Real Life Examples   What is Money Laundering?   Money laundering is the process of making money gained from illegal activities (dirty money) look like money gained from legitimate activities (clean money). An easy way to think about the money laundering process is to break it down into three stages:   Placement is getting the illegal funds into the financial system. This can be the most difficult stage for a criminal due to the regulations of financial institutions regarding the reporting of suspicious activity. If an account were to receive a large amount of cash deposits, this would be a huge red flag. To get around the red flags, the money is broken up into smaller transactions. Layering is moving the money around in an attempt to hide the origins. This can include transferring money between different banks, or offshore accounts. Integration is using the money for legitimate purchases to make the money look clean. For example, purchasing real estate or high value items like art, or luxury vehicles.   Once the money has been reunited with the criminal, there is little evidence of a crime.   Select any image to see a larger version. Mobile users: If you do not see this image, scroll to the bottom of the page and select the "Full" version of this post.     Brief Timeline of US Laws (a brief, non-comprehensive list)   The Bank Secrecy Act in 1970 established recordkeeping and reporting requirements. It required banks to:   Report cash transactions over $10,000 cash with the Currency Transaction Report Identify persons conducting transactions. Maintain a paper trail by keeping records of financial transactions.   The Money Laundering Control Act in 1986 established money laundering as a federal crime. It prohibited structuring transactions to evade the CTR filings and required financial institutions to report any activity known to evade the CTR filing with a Criminal Referral Form.   The Anti-Drug Abuse Act in 1988 expanded the definition of financial institutions to include car dealers and real estate closing personnel which required them to file CTR reports. It also required the verification of identity information for monetary instruments over $3,000.   The Annunzio-Wylie Anti-Money Laundering Act in 1992 required a standard Suspicious Activity Report to be used to report activity and eliminated the Criminal Referral Form. It also provided a safe harbor for financial institutions and its employees from civil liability for reporting suspicious activity.   The Money Laundering Suppression Act in 1994 required Money Service Businesses to be registered and to maintain a list of businesses authorized as agents. It also it a federal crime to operate an unregistered Money Service Business. A money service business is anyone who offers services like check cashing; foreign currency exchange services; or selling money orders, travelers’ checks, or pre-paid access products.   The USA PATRIOT ACT in 2001 was the biggest expansion to regulations the financial industry must comply with.   required financial institutions to have an Anti-Money laundering program with minimum requirements. (more in Part 2 on this) standards for financial institutions to verify and maintain an account. This means verifying names, addresses, date of birth, etc. at account opening and checking against a known or suspected terrorist list. expanded the existing BSA framework to strengthen the customer identification process and criminalized the financing of terrorism.   For more information about the history of Anti-Money Laundering laws in the US, see https://www.fincen.gov/history-anti-money-laundering-laws       Find more articles from SAS Global Enablement and Learning here. ... View more

The purpose of this post is to describe the difference between outbound and inbound mode when working alerts in SAS Fraud Management.    An alert is a work item created to identify potentially fraudulent activity. As a fraud analyst, your primary task is to service alerts by reviewing the activity in the alert. You determine whether it represents fraud, based on feedback from the customer, and resolve the alert accordingly. There are two modes in which you work alerts, outbound and inbound.   When you are assigned an alert by the system, you are working in outbound mode.     Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   You review the activity in an alert and reach out to the customer to assess the activity in the alert (for example, with a phone call). There are two methods for determining how an alert is assigned to you in outbound mode: priority servicing and direct servicing. With priority servicing, the system looks at all the alerts within the strategies that you have access to and chooses the alert with the highest priority and assigns it to you. With direct servicing, you are provided a list of strategies to select from. The system chooses the highest priority alert within that strategy and assigns it to you.   When you perform a search to find an alert, you are working in inbound mode.     When you receive a call from the customer, you can perform a search for an entity (like a customer, a merchant ID, or a card), for demographic information (like name, number, or address) or for a specific alert ID. If you find an alert for the customer, you can check it out. If you cannot find an alert for the customer, you can create a manual alert. When a customer calls and there is an existing alert, you can verify the customer’s information by using the Verification tab.   To learn more information about SAS Fraud Management, please visit https://support.sas.com/en/software/fraud-management-support.html.   Find more articles from SAS Global Enablement and Learning here. ... View more