Detect and Prevent Fraud – Real-Time Data Analytics - SafePaaS

Detect and Prevent Fraud – Real-Time Data Analytics

Detect and Prevent Fraud

How to Detect and Prevent Fraud with Real-Time Data Analytics Question and Answer session.

 

Detect and Prevent Fraud with Real-Time Data Driven Analytics

 

Most companies have a zero-tolerance policy for fraud.  Sometimes, the fraud amount could be considered immaterial, and investing resources to investigate the transaction would be considered as not the best use of resources. In such a case, what should management’s view be? What should the internal audit view be when it comes to advising the Board on defining tolerances for fraud? 

In order to answer this question, we should look at the results of the fraud risk assessment and from the perspective of what the internal control environment is in the organization. It makes no sense to invest a thousand-dollar resource to investigate a 100-dollar petty cash fraud. Hence it’s the board’s decision to then consider the best use of the available resources and to ensure that the organization’s focus is on the high fraud risks. Prashant Naik (Certified Fraud Examiner) recommends to keep your eye on the risk, not on the material amount, therefore the decision taken by the management, internal audit department, and the board would be the correct one.

In an organization, where should the responsibility of Fraud Risk Assessment ownership lie – with the Risk Management Department or Internal Audit Department? 

The simple answer would be that it lies with the risk management department and internal audit would test the effectiveness of the risk assessment process. Many Chief Internal Auditors would face the same challenge that when it comes to discussing the sensitivity surrounding the fraud risk, especially when it comes to admitting the fraud is taking place. That is where the challenge lies,  to have that dialogue with management and agreeing upon the assessment answers of the fraud risk. It’s important to have an ethical culture in place for the various stakeholders to participate in that discussion when it comes to the assessment of fraud risk, then everyone becomes responsible to assess that risk and bring it to the table for monitoring and reporting purposes.

Can the SafePasS system identify false positives or does that require human intervention? And if yes, if the organization is large,
how do the internal auditors address the false positives?

The reliance on our system is critical for you to be able to trust the information we produce, therefore we spend a lot of time looking at the false positives, give you some tools to mitigate and remove those false positives. False positives happen in any exception management system, therefore, they are normal occurrences. We provide two types of false positives, the global false positives which occur because of the data itself. For example, you have end-dated users which you can’t remove, there may be transactions tied to those users that appear suspicious. For example, let’s say you have a purchase order that is still pending approval but the person has been terminated or has left the company and their access has been terminated.  That would be a red flag that our system would produce, but then when you go in and mark a global filter saying don’t show me end users that are terminated and have no access (which is a false positive) you can put that in SafePaaS at a global level.

You can also look at patterns at the local level. You may have certain exceptions, for example, there are interfaces that are flowing into your general ledger. Let’s say some of those transactions go straight into the GL and bypass the approval workflow – that would be a localized false positive which someone may look at and say well why didn’t the journal entries go through approval? They’re getting reviewed a different way, they’re coming in through an interface and there’s no human being involved touching the transactions. On the other hand, if the interface fails, we turn on the monitoring straight away so that any manual intervention or entries that might have come in when the interface failed and that somebody went to correct we start to monitor. It can be sophisticated, it depends on how the organization has implemented systems. To find out more, you can request a personalized demo.