One of our CFE chapter members left us a contact comment asking whether concurrent fraud auditing might not be a good fraud prevention tool for use by a retailer client of hers that receives hundreds of credit card payments for services each day. The foundational concepts behind concurrent fraud auditing owe much to the idea of continuous assurance auditing (CAA) that internal auditors have applied for years; I personally applied the approach as an essential tool throughout by carrier as a chief audit executive (CAE). Basically, the heart of a system of concurrent fraud auditing (CFA) like that of CAA is the process of embedding control based software monitors in real time, automated financial or payment systems to alert reviewers of transactional anomalies in as close to their occurrence as possible. Today’s networked/cloud based processing environments have made the implementation and support of such real time review approaches operationally feasible in ways that the older, batch processing based environments couldn’t.
Our member’s client uses several on-line, cloud based services to process its customer payments; these services provide our member’s client with a large database full of payment history, tantamount to a data warehouse, all available for use on SQL server, by in-house client IT applications like Oracle and SAP. In such a data rich environment, CFE’s and other assurance professionals can readily test for the presence of transactional patterns characteristic of defined, common payment fraud scenarios such as those associated with identity theft and money laundering. The objective of the CFA program is not necessarily to recover the dollars associated with on-line frauds but to continuously (in as close to real time as possible) adjust the edits in the payment collection and processing system so that certain fraudulent transactions (those associated with known fraud scenarios) stand a greater chance of not even getting processed in the first place. Over time, the CFA process should get better and better at editing out or flagging the anomalies associated with your defined scenarios.
The central concept of any CFA system is that of an independent application monitoring for suspected fraud related activity through, for example (as with our Chapter member), periodic (or even real time) reviews of the cloud based files of an automated payment system. Depending upon the degree of criticality of the results of its observations, activity summaries of unusual items can be generated with any specified frequency and/or highlighted to an exception report folder and communicated to auditors via “red flag” e-mail notices. At the heart of the system lies a set of measurable, operational metrics or tags associated with defined fraud scenarios. The fraud prevention team would establish the metrics it wishes to monitor as well as supporting standards for those metrics. As a simple example, the U.S. has established anti-money-laundering banking rules specifying that all transactions over $10,000 must be reported to regulators. By experience, the $10,000 threshold is a fraud related metric investigators have found to be generic in the identification of many money-laundering fraud scenarios. Anti-fraud metric tags could be built into the cloud based financial system of our Chapter member’s client to monitor in real time all accounts payable and other cash transfer transactions with a rule that any over $10,000 would be flagged and reviewed by a member of the audit staff. This same process could have multiple levels of metrics and standards with exceptions fed up to a first level assurance process that could monitor the outliers and, in some instances, send back a correcting feedback transaction to the financial system itself (an adjusting or corrective edit or transaction flag). The warning notes that our e-mail systems send us that our mailboxes are full are another example of this type of real time flagging and editing.
Yet other types of discrepancies would flow up to a second level fraud monitoring or audit process. This level would produce pre-formatted reports to management or constitute emergency exception notices. Beyond just reports, this level could produce more significant anti-fraud or assurance actions like the referral of a transaction or group of transactions to an enterprise fraud management committee for consideration as documentation of the need for an actual future financial system fraud prevention edit. To continue the e-mail example, this is where the system would initiate a transaction to prevent future mailbox accesses to an offending e-mail user.
There is additionally yet a third level for our system which is to use the CFA to monitor the concurrent fraud auditing process itself. Control procedures can be built to report monitoring results to external auditors, governmental regulators, the audit committee and to corporate council as documented evidence of management’s performance of due diligence in its fight against fraud.
So I would encourage our member CFE to discuss the CFA approach with the management of her client. It isn’t the right tool for everyone since such systems can vary greatly in cost depending upon the existing processing environment and level of IT sophistication of the implementing organization. CFA’s are particularly useful for monitoring purchase and payment cycle applications with an emphasis on controls over customer and vendor related fraud. CFA is an especially useful tool for any financial application where large amounts of cash are either coming in or going out the door (think banking applications) and to control all aspects of the processing of insurance claims.