When does transaction monitoring become a control?

Published | Tuesday, June 5th, 2018


Analytics and improving the compliance process

Using the right technology in the right way can do a lot to help reduce the costs and efforts involved in compliance. One of the quickest wins can come from using data analytics to test the effectiveness of internal controls. This is not normally done by directly testing the individual control, but by testing all the transactions that are meant to be subject to that control. If all the transactions appear to have complied with the control objectives, then the control is assumed to be working as intended.

One of the great advantages of using analytics to test controls in this way is that you go beyond the traditional approach of, say, simply checking that a certain control setting in an ERP system is turned on. You can find out whether, despite the setting being on, there is evidence that a problem transaction has still occurred, meaning that the control is not 100% effective after all. You can also determine if there have been deliberate attempts to circumvent the control. So, to take a simple example, you can test to see that all journal entries were approved by an appropriate individual and within their authorization limits. You can then also test to see if attempts were made to circumvent the control by, say, splitting a large journal entry into multiple smaller ones, just under an authorization limit.

Should analytics become part of the control process itself?

There is an interesting issue that arises when considering transaction monitoring as part of a compliance process. Is there a point at which transaction monitoring actually becomes the control? And, if so, is this a problem?

We were asked this question during a recent webinar. The implication was that if transaction monitoring is the control then there is a problem. It is a good topic to discuss for a number of reasons, one being that it can open up a good conversation about roles and responsibilities among the three different lines of defense. Personally, we don’t think establishing transaction monitoring as part of a control mechanism is a bad thing (the reverse, in fact), but it does all depend on who has responsibility for performing and responding to the monitoring.

Whose job should it be to monitor transactions?

If someone in internal audit is responsible for transaction monitoring, no one is likely to see that as an issue in terms of roles, auditors have been using data analytics for control testing as part of the audit process for years. But what if the monitoring is an ongoing process, performed on a daily or weekly “continuous” basis? Is it really the auditors’ job to deal with all the issues that may arise from “red flag” transactions that may or may not indicate actual fraud and errors? Perhaps it is reasonable that someone in the second line of defense takes on responsibility for transaction monitoring. A bit of a mid-point in terms of roles. But why not make transaction monitoring the responsibility of front-line management, the first line of defense? They are the ones directly responsible for maintaining effective controls, so why not have them use the power of data analytics to enhance the control systems that need to be in place? It doesn’t have to replace traditional control systems, even though it may make sense to do so in some circumstances. Just supplement them.

We would argue that having the first line of defense perform transaction testing/monitoring is a very good way of enhancing control and of supporting compliance processes. What do you think?

  Get in touch with us!



In compliance with Section 45 of the ECT Act please confirm the following:

I would like to receive future communication from CQS.



Leave a Comment

Your email address will not be published. Required fields are marked *

*