The Fraud Examiner


Mining Your Travel and Credit Card Data for Fraud, Waste and Abuse
Share |

Editor’s Note: In our September edition, The Fraud Examiner presented “Are Your Travel Expenses Monitored?” by Misty Norris-Carter, CFE, CIA. In response to that article, our guest writer submits his experiences at Mayo Clinic regarding the implementation of data mining processes to monitor travel.  

  

December 2013 

By Erich Heneke, CFE 

  

When I joined the Mayo Supply Chain team back in 2007, we had a smattering of procurement cards across the organization (probably around 600). In addition, we had just required travel cards be used for travel in most or all circumstances. At that time, however, we didn’t have a robust way to audit for fraud or misuse. Sure, we were randomly sampling our cards, but what were the odds we would happen across fraud, waste, abuse or anything interesting? It was only by happenstance that we found issues. The light bulb came on one day when someone external to our department pointed us to a fairly obvious issue with a card; a scenario we probably should have noticed but did not. It was at that time when Mayo began to discuss a risk-based approach. 

  

In 2009, Mayo Supply Chain formed a cross-functional group, locked ourselves in a room and stepped through every single “what could go wrong” scenario as it related to holding a credit card. How would I abuse the system if I wanted to commit a fraud? What would be the ways I (as an auditor) might be able to find suspect transactions and behavior? Any and all thoughts were accepted at this point, even the most bizarre. 

  

The second step was to take each scenario and match it against all the data we had available to us, including the credit card system, ERP, expense reimbursement system, etc. If we didn’t find a piece of data we needed (and thought someone would have), we asked for it. And often, we found it was available, somewhere. 

  

Here are some of the items that floated to the top of Mayo’s credit card risk assessment: 

  

RISK 

DESCRIPTION 

(SusMer) Suspect Merchant 

Detects risky vendors by category (vendors that sell high volumes of liquid and/or personal items) 

(SusTransAmt) Suspect Transaction Amount 

Detects even dollar purchase amounts, suggesting gift cards OR very high, suspect transactions (items that should be capitalized) 

(SusTransTime) Suspect Transaction Timing 

Detects sudden peaks in spending which may indicate personal charges (holiday shopping, weekends, overnight hours) 

(MissApp) Missing Approvals 

Detects paid transactions not appropriately approved by the cardholder and/or supervisor 

(HR) HR Status 

Detects terminated or employees pending termination 

(MultCard) Multiple Cards 

Detects multiple cards issued to one person in error (or on purpose) and/or excessive total limits 

(ExLim) Excessive Limits 

Compares limits to actual spend to detect suspect spend limits 

(TransDup or TransSplit) Transaction Duplicate/Split 

Detects possible duplicate charges and split transactions to avoid single transaction limits 

(Inact) Inactive Status 

Detects inactive cardholders who may no longer need cards, lost cards and/or terminated employees 

 

This was the easy part of the process.  Performing a risk assessment and tying to data is pretty straight forward. If you’re looking for “Suspect Transaction Amount” (from the table above), then the data you’re seeking is the $25, $50, $100 and $500 transactions or those that are more than $100,000 (for example).   

  

Our next step was slightly more difficult: scoring the above mentioned risks. In order for our reviewers to have the complete picture, we elected not to look at just one or two risks, but to sum the risk together in order to derive at a ‘total risk score’ by employee. As one might imagine, this is somewhat an arbitrary exercise until you can review the results and tweak your scores to line up with the data. However, we took a shot and attached a risk score to each of the risk factors.   

  

Now for the tough part: mining the data. Unfortunately, this is where most well-meaning departments fall short. We elected to use a popular data mining software and internally grow a group of people who could script for us. A lesson learned during this process was the amount of time it would take for the team to learn the software. It’s very complex and requires a lot of practice, error, correction and ultimately success to get the hang of it. Most people will throw in the towel at this point, thus the reason for the recommendations for those who wish to try it (see below). 

  

What was the end result? A very interesting scorecard that looked something like this (abbreviated for the purposes of displaying the output): 

  

  

Cardholder 

G. Jones 

J. Smith 

E. Miller 

T. Larson 

Risk Factor 

  

  

  

  

  

SusMer 

  

5 

10 

5 

  

SusTransAmt 

  

  

10 

10 

5 

SusTransTime 

  

  

15 

10 

15 

MissApp 

  

  

5 

20 

5 

HR 

  

10 

  

  

10 

MultCard 

  

5 

5 

5 

5 

ExLim 

  

  

  

20 

  

TransDup 

  

10 

  

10 

  

TransSplit 

  

  

  

  

  

Inact 

  

  

10 

10 

10 

  

  

  

  

  

  

Total Score 

  

30 

55 

80 

50 

  

Based on the above table, most can immediately determine who is the highest risk and where audit resources would most effectively be used. Would you audit G. Jones? Perhaps, but probably not before you’d carefully study part or all of E. Miller’s transactions. The way Mayo designed the system was so the data could be run over and over (monthly) and any risk factor could be tweaked in the future.  However, we have held fast that the total risk profile should not be a moving target; rather reviewed and refreshed annually in order to keep its integrity. 

  

Additional Consideration for Travel 

Mayo’s travel card/credit card policy states that travel-issued cards are to be used only for business purposes. To some, however, a credit card in hand may offer a temptation to use it for personal reasons. Due to this heightened risk, Mayo Supply Chain elected to build out some additional functionality to monitor specific transactions for the travel cards. The specific, non-scorecards scripts we produced in addition to the above were: 

  

Risky Merchant Category Codes (MCCs): Our group took a look at all MCC codes offered and determined which were least likely to be for Mayo business. We mined our data against those specific set of codes in producing a “Risky MCC” report for review (Mayo has elected to keep most MCC’s available for use given our very unique and diverse business needs).

Personal Expenses: In Mayo’s travel reimbursement system, all expenses that hit the card are eventually tied to an expense report.  In instances where a cardholder marks a transaction as “personal” in the expense reimbursement system, we are immediately alerted that the transaction was not for business.  This allowed our team to mine the data for high incidences of ‘personal’ expenses.

Local transactions: This allowed us to place a target around the employee’s home geographic area and search for high volumes of transactions locally, suggesting personal use.

  

Mayo’s Results 

When I speak about this topic, the first question I’m asked (if I don’t spell it out) is, "what are Mayo’s results in this analysis?" I would group our most interesting findings as follows: 

  

Droves of local transactions: Because we hadn’t specifically been looking for local transactions up until this point, we found a somewhat widespread use of cards right in town. While some of the things that were purchased were legitimate (such as business dinners), some were not. As one might expect, we also detected a spike during November and December.

Gift card purchases: We discovered a moderate number of gift card purchases, which allowed us to educate cardholders on the proper way to get gift cards for their area, if applicable.

Cardholders procuring incorrectly: While not fraudulent, we discovered several instances where a credit card was the incorrect way to procure (example: computers and software).  This again gave us a chance to educate on how to do things correctly.

Interesting MCC use: We discovered several ‘interesting’ MCCs used during our analysis, including one to a boat shop. This particular transaction did turn out to be business related, but it initially set off sirens all throughout our group.

  

Additional Mayo Benefits 

The second most common question I’m asked goes something like this: “Erich, I think the technology sounds great and I’m excited to get started. However, at some point, I’m going to have to explain the return on investment to my boss. How do I navigate that question?” 

  

This is a complex question. As CFEs, we all understand fraud, its costs and that a continuous monitoring process likely will pay for itself. But how does one explain that ROI will be realized later? It’s a tough argument. In answering the question, I offer these items for the ROI consideration: 

  

If you assume just 2 percent of your spend is fraudulent (a conservative estimate), what is your ROI?

If you have continuous monitoring in place and thereby your management team is comfortable in moving $(amount) from checks to credit cards, what is your annual rebate?

If you move $(amount) from checks to credit card, how much do you now save in check processing?

What is the amount of float you can achieve in moving to credit cards?

  

In particular, numbers 2-4 can add up really quickly. If an organization moves just a few million dollars in spending to a card, they can realize hundreds of thousands in reduced costs and rebates. 

  

A Note About Expense Reimbursement Systems 

Many confuse what an expense reimbursement system does versus what this type of continuous monitoring does. Expense reimbursement systems look for specific breaches of policy. For example, is the hotel expense <= $400/night? The output is a yes or no. Expense reimbursement systems do not look for fraud, they look for compliance to policy. Layering an expense reimbursement system on top of a continuous monitoring, data-driven process arms you with a very powerful, robust solution. 

  

Suggestions and Conclusion 

I’ve presented nationally many times on this topic. The issue of mining tens of thousands of rows of data for anomalies has been a hot topic in nearly every venue I’ve spoken in. Why? I believe it to be two reasons: 

  

1. Most astute business people (and in particular those with a fraud background) understand why there is relatively little value in random sampling, or put another way, why there is such high value in selective sampling based on data-driven risk. 

2. When it comes to data mining, many organizations get excited about the concept, but most will fail in implementing. Why? Because data mining isn’t as easy as it sounds – it requires sophisticated people to use difficult software. Most times, the people who really want to use the software have no background on how to make it work. That isn’t a slight on auditors or forensic analysts whatsoever. I’ve heard over and over from others, “Gosh, data mining is really hard to do. We thought we could figure out how to use the commercial software, but it was too difficult.” 

  

While the idea of data mining, scorecarding and intentional, risk-based auditing is wildly popular at Mayo and with others in the industry, it’s really, REALLY hard work. The road is often long, winding and unpredictable. To conclude, I would offer the following recommendations for those who are interested in pursuing this path: 

  

Before beginning, ensure you have the proper IT/programming resources to engage.  Often, people in internal audit know how to use this type of data mining software, but more often, they do not have resource time to offer.

Be realistic in how much of your risk you can cover down.  Most go for the grand finale when even just a couple of reports would go a long way.  Start small and build your risk assessment out over time.

Consider outsourcing some or all of the process. If your organization is great at building risk assessments but lousy at programming data mining tools, consider outsourcing the data mining to someone who’s really good at it. There are some powerful data mining tools in the industry that automate much of what our process does today.

  

My team was fortunate in having support throughout the organization and help along the way. We were thrilled to be recognized not once, but twice by industry innovation groups (Alexander Hamilton and Huntington Innovation Awards). Through some patience, careful planning and hard work, Mayo is pursuing a web-based solution that meets its needs and ties closely to its current data-mining processes. 

  

For questions related to this article, contact Erich Heneke, Senior Manager – Supply Chain Management, Mayo Clinic at heneke.erich@mayo.edu. Disclosure: Mayo Clinic and Erich Heneke have a financial interest in this technology. 

 

  

Contact the ACFE
For more information, contact Scott Patterson, Media Relations Specialist
Phone: (512) 478-9000 ext. 156; email: spatterson@acfe.com

 
 

1 Comments

  • Avatar

    Interesting! Risk assessment is one approach. I'm experienced in recovery audits, searching for fraud, waste, abuse and disbursement errors. Then seek restitution for recoveries from the findings, either from vendors or fraudsters. One of the methodologies is data mining using transaction analytic. The transactions are dissected and slice into different types to detect abnormalities, unusual pattern, irregularities, correlations and spikes. Examples: Transactions are organized by dates, vendors, purchase types, amt, invoice #, address, check disbursements, etc. Potential duplicate pymts, over payments, over-billing, fictitious billings/expenses, split transactions, duplicate credits, etc can be detected and reviewed with actual invoices/billings/expense reports. P-cards that are deliberately used to initiate credits for returned goods (unused credits) can be exposed. Some transactions are buried deep in line item details. Organize the transactions by line item details will flag these anomalies.

Add Comment

Text Only 2000 character limit

Page 1 of 1