Hello. My name is Ben Davidson. I am a member of the SAS Visual Scenario Designer team, and I recently interviewed Jamie Hutton, Principal Business Solutions Manager and Solutions Lead of Fraud and Financial Crimes at SAS. Jamie has been with SAS Visual Scenario Designer since the early stages of the product, and was kind enough to share his expertise with the SAS community.
Q: Can you describe your role within SAS?
A: I have a number of roles, varying from pre-sales to product management. I visit customers in the field, collect feedback, prioritize it, and bring it back to R&D for inclusion in future releases.
Q: What need in the marketplace is SAS Visual Scenario Designer addressing?
A: VSD was built to detect and prevent fraud and financial crime.
Q: SAS Visual Scenario Designer has been described as a “data-driven solution for interactive rule and scenario authoring, testing, and validation,” instead of a traditional “rule-based solution.” Can you describe this difference?
A: Rule-based solutions are designed to allow users to put a known fraud/compliance risk into a detection system. With a data-driven solution, you use historic data with existing known outcomes to automatically detect what the rule should be. You don’t have to rely on an investigator knowing what’s suspicious; instead, you use the data to tell you what’s suspicious.
Q: So you’re using previous facts rather than hypothetical guesses?
Q: Can you briefly walk us through how a user will typically use SAS Visual Scenario Designer?
A: There are two use cases:
One is the ongoing daily changes that people are going to be using VSD for. Once the system is in the production, the data manipulation tasks are mostly complete. So what users are doing are inputting new fraud trends into the system, which they do by building scenarios. They are building those scenarios based on the data that is already set up within VSD. Or they might be retuning an analytical model. They might be doing this once a week, as a new fraud trend emerges.
Then there is the more technical setup, which likely happens at the beginning of the project. That would be in combination with the fraud experts and with IT. This would be the data aggregation stage, getting it ready for the scenarios that you want to write. In VSD, this is the process of creating windows.
Q: After installing SAS Visual Scenario Designer, what are the first actions that a user will likely do?
A: We are trying to position VSD so that, out of the box, it is configured and comes with industry IP: real templated windows and scenarios such that detect specific types of fraud. The customers then work out which additional rules to add, how to weight the rules, and what kind of overall risk scoring model they want to apply.
Q: After a user has authored, deployed, and simulated his or her scenarios, what next?
A: Fraud never stands still, so it’s the ongoing tuning. We call it the “squeeze balloon effect.” If you stop the fraudsters on one side of your organization, then they’ll pop up somewhere else. The reason that VSD is so powerful is that allows you to be so agile, to make the necessary changes as those new fraud schemes evolve.
Once the detection model is complete, there are two ways to execute what comes out of VSD:
Q: SAS is a company built on analytics and data. Are there specific ways that SAS Visual Scenario Designer leverages this expertise?
A: The whole solution is data driven. Data analysis, data manipulation, and data aggregation are strong points for SAS and VSD removes the technical requirement and enables a business user to undertake those activities. On the analytic side, VSD has decision trees, and the expectation in the future is for additional analytics to be made available.
Q: What are some ways that SAS Visual Scenario Designer enables users to create better rules, with fewer “false positives”?
A: This comes back to the testing on high volumes of data. The key thing about VSD is that you have a hypothesis, a scenario that you want to investigate, and then you instantly test it on production-level volumes of data. That tells you how many alerts you will get and how many of those alerts were previously marked as fraud. So you know instantly whether your scenario is good, or whether it has a very high false-positive rate. This is a very different approach from a slow moving approach where business comes up with an idea, IT implements it, and then analysts provide feedback. In VSD, the business user is in charge of that entire lifecycle.
Q: You mentioned the integration with SAS Event Stream Processing Engine, SAS LASR, and SAS Visual Analytics. What’s the benefit of this integration?
A: VA Explorer enables you to explore your data and find new, previously unknown fraud trends. VSD then allows you to take these findings and proactively alert on these going forward. What we suggest to our customers is that they use VAE as their exploration and discovery environment, then use VSD to complete the loop of exploration to generate alerts.
In terms of SAS Event Stream Processing Engine integration, I think the key differentiator here is the speed and the complexity at which ESP can make decisions in real time.
Q: Do you have any particular best practices or usage advice for someone who is new to SAS Visual Scenario Designer?
A: Any user needs to understand the types of window behaviour and what each does with the data, as well as the data aggregation concepts. In my view, data preparation is 80 percent of the work prior to creating your rules. So users should read the VSD documentation to understand these types of window behaviour.
Q: In what industries do you see SAS Visual Scenario Designer being especially helpful?
A: Within the Fraud and Financial Crime division, we’re looking to use VSD across all fraud and financial crimes solutions (fraud and AML). Banking, insurance, government, healthcare, and telecommunications are the primary industries. However, VSD could easily be used outside of those areas.
Q: If a company already has an anti-fraud solution in place, would they still find SAS Visual Scenario Designer useful?
A: Our aim is always to replace the existing solution with a SAS solution, because we believe that the SAS solution will deliver better value. Lots of customers are replacing their legacy systems with SAS solutions. VSD would be a key reason in helping drive them to do that.
However in the situations where there is a deeply embedded legacy system, we have deployed VSD alongside those existing systems to optimize and tune them. VSD becomes an offline analytic environment to find new rules and scenarios and to test them, so that the customer can put these new rules and scenarios into their legacy rules engine on their existing system.
Q: Are there any shortcomings or limitations of traditional anti-fraud applications that SAS Visual Scenario Designer is able to overcome?
A: I would argue that IF>THEN>ELSE rules engines are ubiquitous in the market. In my view, getting data ready for the rule is most of the challenge, rather than writing the rule itself. VSD allows a user to do to a lot of data preparation and aggregation prior to running the rules. For example, if we are trying to score a transaction, we are going to score it based on the aggregate behavior of the customer, account and beneficiary - these derived behaviors are set up through what VSD calls “windows.” Windows aggregate the data and then re-summarize it in a different way to generate statistics that can be used to create much more complex scenarios.