Hello, you are not logged in.  Login or sign up
Community >> Blogs
Search Toad World Search

Blogs
Toad and Database Commentaries

 Toad World blogs are a mix of insightful how-tos from Quest experts as well as their commentary on experiences with new database technologies.

Do you have a topic that you'd like discussed?  We'd love to hear from you.  Send us your idea for a blog topic.

How to Help Your Company with Financial Risk
 
Location: Blogs John Weathington's Quest for Compliance    
 JohnWeathington Thursday, July 31, 2008

Risk is a topic that’s being talked about a lot lately, especially in the financial / SOX arena. Here’s why.

New SEC Standards Mean Risk is the Way

When SOX first rolled through, the focus was purely on rule-based controls. That’s because GAAP ( Generally Accepted Accounting Principles ), the guideline that is used for the more salient SOX related exposure, is a rule based system. Meaning, the FASB ( Financial Accounting Standards Board ) determines the proper ways to do accounting, then creates rules that must be followed. Good companies follow the rules, and don’t have SOX problems, because the SEC ( Securities and Exchange Commission ) has determined that as long as GAAP rules are being followed, public companies are in compliance with SOX ( at least that section of SOX ). This was in the early days of SOX, when AS2 ( Auditing Standard 2 ) was the guideline of the day.

AS2 has been recently superseded by AS5 ( Auditing Standard 5 ). This was mainly in response to the overwhelming concern by the big companies that had to go through SOX compliance, that the process was too costly. AS5 attempts to remedy the situation by introducing the concept of a risk-based, top-down approach to control. In theory, this should reduce the cost of compliance for your company (although recent studies have shown that this is not proving true ).


AS5 carries both good news and bad news for your company. The good news is that they don’t necessarily need to worry about all the rules that drive every line item on their financial statements. This is the risk-based portion of the standard. Your company is at liberty to focus only on the high-risk items, and for all intents and purposes ignore the low-risk stuff. The bad news is that your company has to do some work on financial risk analysis, which they’re probably not used to.

How This Relates to Database Professionals

This is where you come in.

As usual, there is a great deal of value you can provide in helping your company conduct its financial risk analysis and further justify its decisions. I just read today that over half of the CFOs that are attesting under AS5, are unsure of what financial items to consider as high risk. I guess this presents a problem, when trying to follow a standard that’s predicated on a risk-based approach!
So, before we design, let’s reflect on what constitutes financial high-risk in the eyes of the SEC. The overriding risk for all of SOX compliance is that there are financial inaccuracies in the published financial statements. These are the numbers that the investors trade on, and the SEC is holding your company’s CEO and CFO responsible for making sure these numbers are right.

Earlier in the year, we discussed the different ways to control risk ( Reconciliation, Approvals, Segregation of Duties ), and the risks that involved with these controls. We’ve also talked briefly in Prevention over Intervention, about some design considerations for a compliance data warehouse. The natural extension would be a compliance data mart. A compliance data mart is a subsystem of your entire compliance data system. As you might suspect, the compliance data mart is used for strategic aggregation and reporting of compliance data.

The Financial Risk Compliance Data Mart

One design consideration I have for addressing financial risk in your company, is to build a compliance data mart that specifically addresses this concern. It’s a big enough concern to warrant such attention. The goal of the data mart, is to provide a strategic reporting environment where auditors and finance executives can analyze the company’s ability to report accurately.

You would follow a typical star schema format. The fact table would contain data about exceptions / violations that were caught in the upstream components of the compliance data system. For instance, you may have a reconciling control in place that catches when balances are out of sync. Or you may have designed in an approval control to catch the risk of people making mistakes.

If you’ve been following my advice so far, in any and all of these cases, you should have a violation or exception table that highlights control violations. This is the data that you will aggregate in your fact. A metric such as violations per day is a great example of something to capture. You can also feed in data from previous audits, where the auditor has found discrepancies.

Of course you would also have dimensions. Some typical dimensions would be: period, financial item ( i.e. gross revenue, depreciation expense, etc. ), exception type ( i.e. recon, approval, SOD, etc. ), business unit, and others that seem to make sense for your organization.

Once the star schema is in place, create reports against it that highlight the areas that are financially risky for your company, from an internal control standpoint. This data will be extremely valuable to your finance executives, and will give them a platform for justifying what they call “high-risk” on their financial statements. Of course there will be other interpretations of high-risk, but your approach will provide a very objective base to drive from.

In Summary

You’ll be hearing a lot more about risk in the compliance arena, as the industry starts moving more in that direction. Financial risk is just one example of something your company is probably trying to wrap its arms around. The introduction of a Financial Risk Compliance Data Mart, a data mart that highlights risky areas of the financial statement, can be a great asset to your company’s financial executives. Take some time today to explore this with your finance and / or audit team.

Permalink |  Trackback

Comment:
Add Comment   Cancel 
Search Blog Entries
 
Blogger and Topic List
 

 

All Recent Entries
 

 

Johannes Ahrends
Unicode

Steven Feuerstein
Oracle PL/SQL

Daniel Norwood
Toad for Data Analysts
John Pocknell
Toad for Oracle
Bert Scalzo
Toad for Oracle, Data Modeling, Benchmarking
Jeff Smith
Toad product family
Richard To
SQL Optimization
Jim Wankowski
DB2 - LUW and z/OS
John Weathington
Compliance
Doug Williams
Database Musings
  Henrik "Mauritz" Johnson
Toad Tips & Tricks on the "other" Toads
  Toad World Editor
Toad World issues

  Toad Data Modeler Opens in a new window
Data Modeling
 

Copyright 2008 by Quest Software  | Terms Of Use | Privacy Statement | Contact Us