Governance
Monitoring and Tuning of Analytics Solutions
Contents
Audit and control is an essential component of analytics solutions and is required to be in place before business decisions are carried out using analytics. The purpose of analytics is to stay ahead of actual events and have some future perspective and predetermination of business transactions. Since analytics enables proactive actions on events as soon as they happen, it is important to have a tight monitoring on those decisions to prevent damage from mistakes, abuse, and even incompetence. The tools and approaches for audit and control of analytics-driven automated decisions are not very different from the ones needed by owners of the models and strategies who track their performance. The only difference is that the audit team has to be outside of the typical IT and business groups responsible for tuning and modifications of models and strategies.
Analytics and Automated Decisions
Here is how analytics enables automated decisions as we have seen in the previous chapter:
■ Regular business operation carried out by operational systems generates data.
■ Data is accumulated over time to build history.
■ Historical data is used to develop insights into what has happened and how business has been performing.
■ Analytics models are built from historical data to influence future business decisions.
■ Decision strategies are built on analytics and integrated with operational systems for automated decisions, with minimal to no manual intervention.
The benefits of this entire approach are well articulated, well understood, and widely adopted as described in previous chapters. Some of them are:
■ Superior efficiency and speed compared with the manual process.
■ No time and geography constraints—systems are up and running at all times and looking into all aspects of the business across all time zones. Humans have serious limitations with time and geography.
■ Real-time and event based—once a system detects an opportunity, it follows up and executes the decision accordingly.
■ There are no hidden agendas, ideological beliefs, and biases when a system automatically makes decisions.
However, there are some downsides of this approach that are not as widely understood and addressed:
■ The analytics models and their accuracy are dependent on the input variables. If the input variables become irrelevant because of changing business conditions, the models become stale and their output may not be as reliable, but the automated decisions wouldn’t necessarily know that (e.g., AAA-rated mortgage securities during 2008 economic crisis; Financial Crisis Inquiry Commission, 2011).
■ The conditions or scenarios as laid out in the decision strategy have to occur exactly as designed for the automated decision to work. If there is a slight bit of difference in the real-time event compared with how it has been lined up in the strategy, the decision will not take place as intended. The default conditions and ensuing decisions can therefore be unpredictable, as not all possible real-world situations can be anticipated and addressed.
The Risk of Automated Decisions
The downside of analytics-driven automated decisions is the risk of incorrect decisions that are carried out automatically without detection until it is too late. There is plenty of evidence that automated decisions in trading of equities have suffered from this symptom where the systems kept making the trading decisions, creating a snowball effect and compounding the negative effect (losses). These trading decisions have analytics models and decision strategies behind them covering various scenarios, and they make automated decisions without human supervision. There are automated decisions that if incorrect can result in losses.
Another risk is inaction leading to lost opportunity, where the scenario was slightly different than the one coded in the strategy and therefore no decision was made.
Another risk is wasted resources, where a remedial action was taken, such as refinancing a loan or rerouting a shipment, when it was not required in the first place (this is mostly because of false positives). Does the risk of incorrect decisions outweigh the benefit? Should we stop using decisions based on analytics models and automated decision strategies?
Monitoring Layer
Instead of adopting an either-or approach (use automation or not in decision making), we will try to build a monitoring layer on top of the analytics-driven strategies to mitigate the risk of incorrect decisions. The rest of the chapter is dedicated to details behind building and using this monitoring layer.
Audit and Control Framework
The audit and control layer is designed and built the same way as the reporting and analytical layers within the Information Continuum. Operational systems carry out the business operation and generate data. The data is used to measure and keep an eye on the business. Now that analytics-driven automated decisions are being used, it is yet another form of business operations carried out by decision strategies integrating into the operational system. Therefore, a new reporting and measurement mechanism is needed. Automated decisions have two parts: the part relevant to the analytics and the strategy, which includes information such as:
■ Analytics model name/ID, type, and version used in the decision
■ Decision strategy name/ID and version
■ Input record values (the input variables required to run the model)
■ Decision path within the strategy
■ Input date/time, source system for the input record, ID used, output date/time for the decision, etc.
This information is actually the metadata about the automated decision. The other part is the real data of the transaction, such as approving a case, sending a coupon, buying a commodity, etc., and that data still lives in the operational system and is recorded in the same manner as before—it is carried into the data warehouse and reported against. That is, the actual data is recorded in the operational system and the traditional data warehouse system. The analytics decision metadata is recorded in the analytics datamart. The audit and control information is within this metadata in the analytics datamart. We will see what information is relevant and how to use it.
Organization and Process
The audit and control organization has to cut across various analytics projects. The idea of adopting analytics in the manner outlined throughout this book is to make it available to all business functions across an organization. That requires audit and control monitoring to be in place within each business function that is carrying out automated decisions using analytics models. Instead of trying to create that role within each business function, a centralized audit team ideally within the internal audit department should be built. There is nothing special about the audit of automated decisions, and any trained auditor should be able to pick up the new role. Most of the audit activity has to be automated anyway.
The process that the auditor has to follow is based on standard reports that show summaries and trends of decisions being made. The data is moved into the audit datamart from the analytics datamart and then the reports run and provide visibility to the auditor about what is going on. This is a reactive mode and will be needed in the early stages of analytics adoption. Once the automated decisions have been in place for six months or so, there will be some patterns and trends available that can allow setting up thresholds, alerts, and triggers. The auditor will be able to set these up and tune them. Some will be set up just for monitoring purposes and some will act as a circuit breaker to override the automated decisions being made.
Audit Datamart
The audit datamart design will follow the design principles as widely understood and used within the business intelligence and data warehousing space. The audit datamart is a classic datamart designed for auditing users who have an interest in specific audit data to be extracted from the analytics datamart and the data warehouse and loaded into a separate auditing datamart. Figure 6.1 shows an illustration of the audit datamart. Only analytics-driven automated decision entities are presented, and it is expected that each organization will introduce its own flavor of audit to this data structure.
The decision summary fact table records the decisions being made by the decision strategy integrating in the source system. Its grain can be at each decision level, or if bulk decisions are being made, then it will have aggregate data. The decision code is the decision that the strategy eventually takes. For most predictive modeling solutions and strategies, there will be typically three decision codes. For example, in case of a loan application, the three decisions can be accept, reject, and review. The decision factors in the predictive model’s output that assigns a probability of default, and then the strategy looks at the overall situation of the applicant, the loan offer, or the product specifics, liquidity, and lender’s overall strategy, etc. to make a decision, but the overall possibilities of a lending decision can have just three codes. The threshold and alert tables are not the typical datamart tables. The threshold table is set up by the auditing team with respect to automated decisions. They can put thresholds on certain decision code or allow only certain counts or values of decisions to go through. Once a threshold has been designed and inserted into the threshold table, any breaches will get recorded in the alerts table. These are broad ideas to consider when designing an audit datamart for analytics.
Like all datamarts, this process will use all data warehousing best practices, such as the use of an ETL tool to load data in the audit datamart, regularly scheduled data feeds, data-quality controls, etc. In addition to the data management for the datamart, the front-end or the presentation layer of the audit datamart has to follow suit. The same reporting tool used by the rest of the data warehouse for reporting should be used for the audit reporting.
Unique Features of Audit Datamart
The audit datamart will have some uniqueness in its implementation compared with the other datamarts within the data warehouse:
1. The loading, backup, and archiving schedule will have to be shared and signed-off by a member of the auditing team.
2. Any data discrepancy or data-quality issue will also go through a more rigorous investigation.
3. Any changes to the datamart will have to be signed-off by the auditors.
4. Separate logs will be maintained for users accessing the datamart and running queries and reports. The logs will only be accessible by the auditors, and they will decide when to discard or archive the logs.
5. The presentation layer accessing the audit datamart will have tight security and access controls. Most BI tools have robust security and access controls and they should be used to limit the access to the audit datamart.
6. The threshold table will have a separate load interface controlled by auditors to change various thresholds or remove or add new ones. A small application with appropriate security controls may have to be built.
7. The alerts table can be set up to run nightly to look at the data for the day, check against thresholds, and generate an alert when a threshold is breached.
Control Definition
Designing the thresholds is a complicated task. It involves clear understanding of the business process, the problem definition for which the model has been built and used, the various scenarios and decision parameters used in decision strategies, as well as the risks of incorrect decisions. It is very unlikely that an organization has this knowledge readily available within a team or department. The auditors by design are required to maintain this level of understanding for critical functions within the organization. However, we are proposing democratization of analytics-based automated decisions and not limiting to a handful of functions around financial transactions. The purpose of highlighting this issue is for the management and decision makers, essentially the champions of business analytics within the organization, to understand the challenge of auditing automated decisions. There are three methods of designing the control that are presented next, and it is up to the individual organization which one provides the best alignment with their internal audit organization’s culture.
The underlying idea in all three methods is that the process of auditing should be automated as the decisions are automated. If the decision monitoring is automated, then controls and thresholds are needed to put in circuit breakers that trip the automated decision process.
Best-Practice Controls
The best-practice controls are controls that can be copied from published case studies or other guidelines shared in courses, trainings, and marketing material. These are typically available for a specific industry and use. If we look at the automated decision controls and circuit breakers that have been put in place at the New York Stock Exchange, they were in response to an event in May 2010 that came to be known as “Flash Crash.” Learning from that mistake of allowing automated decision systems to keep trading in stocks, most trading exchanges have put in monitoring controls with appropriate circuit breakers that get tripped, and the source of suspicious trading orders is identified and excluded.
It will be awhile before such case studies will be widely available for other industries and problem domains, and therefore the best practices that can be followed will be driven from parameters to look for and building an internal control. For example, an analytics-based automated decision system put in place that looks at a customer profile or a customer activity and offers a discount on another product. There are no guidelines as to how many such discounts should be offered. What if too many customers show up on the website and receive discounts? However, the best practices are available to aggregate the discounts until a budgetary threshold is reached. Similarly, for a credit card online-approval automated decision system, there is no best practice on how many applications should be approved, rather the liquidity and risk-adjusted capital ratios that are well established within a lending operation act as a threshold. Existing controls and thresholds should be used initially and then improved over time adjusting to the unique nature of automated decisions.
Expert Controls
The expert controls, as the name suggests, are controls designed by experts. Designing expert controls is very similar to designing expert rules in decision automation strategies. Domain knowledge and years of experience allow an expert to build some subjective controls that they use in their day-to-day activities to manage operations. Experts should be interviewed extensively to understand what triggers their curiosity in a certain situation and how they react looking at the changing business situations. The reports that they review from the data warehouse should provide plenty of clues as to what pieces of information are critical to their decision making and should act as controls.
There are no specific guidelines on expert controls. If domain experts are available who are data-savvy and have been using good judgment in utilizing their subjective controls in the past, use that knowledge and convert it into a formal implementation of controls through a system of triggers and alerts within the audit datamart.
Analytical Controls
Analytical controls deal with building a “business as usual” scenario and flag the decisions that do not fit the profile. The establishment of this scenario requires historical data analysis very similar to how decision variables and cutoffs are used when quantitative rules are being devised within decision strategies. Some examples are:
■ Typical volumes of automated decisions expected and actually carried have to be part of the controls, so if typical volumes exceed by more than 20%, someone is alerted. If volumes exceed by more than 35%, maybe the system should stop.
■ Identification of duplicate decisions is another important control that can prevent problems in the operational systems from causing serious damage.
■ Once the analytical controls are in place, they also need to be monitored to ensure they remain relevant to the changing business scenarios.
■ Additional controls may be needed to track the changes in controls.
How sophisticated the controls need to be and how much influence they need to have on automated business decisions will vary from business application to business application. Financial transactions certainly would need a higher level of sophistication versus something like office supplies procurement. The bigger the impact of the decision strategy, the higher the focus on decision monitoring and control
Reporting and Action
Some controls will be in real time and will be measuring and reviewing the actual decisions against established thresholds and patterns. Most of the reporting and analysis of automated decisions is almost identical to the people responsible for designing, testing, and tuning new decision strategies. Same data is needed by both, but an additional layer of monitoring is needed to reduce the chance of costly mistakes, incompetence, and corruption. Identical data will be recorded in the analytical datamart for champion–challenger and tuning analysis and the audit datamart since, essentially, both are trying to understand what happened with automated decisions. Auditors need a fast-reacting environment to contain the potential damage.
The audit datamart, similar to most datamarts within the data warehouse environment, would need a reporting tool with good ad-hoc capability so auditors can investigate issues. All the best practices of reporting from the data warehouse have to be put in place on the audit datamart along with tight security and access schemes. A somewhat automated control creation mechanism has to exist to keep track of new controls (metrics and their thresholds) getting added and previous ones modified or removed. If a control has changed, there should be some audit trail of who changed and when and why.