Process Exception Controls

What is it?

This sort of data control works on the basis that when that we see something happen in one place, we expect to see a reaction of a predictable nature in another. It requires a detailed understanding of a business process and can identify each occurrence of an issue, sometimes in near-real time, and so can allow for rapid correction of those issues to ensure the delivery of the desired outcome in a manner that can be indistinguishable from normal service. In short, it spots a single instance of a predicted issue happening enabling you to fix it and keep things progressing correctly.

How does it work?

This type of control requires us to know that in each case where A happens, B must also happen.

The control is simple in its architecture, as it requires only that we are able to identify each instance of case A and then match it to its counterpart B. Where B cannot be found or is found to be in error, then the control must generate an alert requiring that the specific case in question be remedied.

These controls often check basic facts about customer or process data and ensure that it has been accurately replicated between systems or has been correctly processed. They can be wrapped around specific processes where there are known quality conditions and are especially useful where each and every breach needs to be corrected.

Example: Orders Taken Vs. Dispatched

In the example, there are two issues. Each of these could be picked up by a process exception control.

The first issue is that the order for James T Crick hasn’t been dispatched.

The second is that Miss K. O’Toole’s order has been copied incorrectly and has come out as Miss K. O. This kind of error can be quite common if apostrophes aren’t handled correctly when processing data so it may be that a change needs to be made to the system here to prevent that from happening again but we’ll not handle that here – for now we’re interested in looking for these types of cases.

You could handle both of these in a single control but it can be useful to break these down into more specific cases especially where the action you wish to take on each case is different. This allows you to trigger the alerts to different people or teams with their own action plans so let’s assume that here and propose two process exception controls…

Control 1 – Ensure all orders are dispatched within 3 days of being placed

An Exception should be triggered where: No dispatch record is found and we have allowed at least 3 days since the order was placed.

Steps:

1. Find all orders taken

2. For each of those orders, look for a record of the order having been dispatched

3. If there is no record of the order having been dispatched AND the order date is older than 3 days from today, trigger an exception

Result: The order for James T Crick is identified as not having been dispatched yet and will be reported for someone to look into.

Note that in the example here, if we find that an order has been dispatched but that it has taken longer than 3 days, it will not be reported as an exception. This is not an error; it is a deliberate part of the control design and I will come to this in more detail when I discuss some more advanced concepts in control design. It’s important to remember that the aim of this type of control isn’t to report each breaches of an SLA – it is to trigger corrective action to remove or minimise the impact of the spotted failure.

Control 2 – Ensure all orders are dispatched accurately to the person named on the order

An exception should be triggered where the name on the order dispatched is missing or different from the order placed.

1. Find all orders taken

2. For each of those orders, compare the name on the order dispatch list

3. If there is no name or if the name is different, trigger an exception

Result: The order for Miss K O’Toole is has been sent to dispatch with incorrect information and should be held for additional checks.

This check may not be essential in this particular case, as the error would simply be a small addressing issue on the dispatched order, however this sort of check can be exceedingly important in other scenarios. For example, I’ve seen this exact type of control used to identify internal cheque fraud. On that occasion, someone with the ability to issue cheques on behalf of the company would make a cheque out to themselves and record it in the company books as a legitimate payment to suppliers so it would not raise any suspicion in someone looking at the internal company ledgers. By cross-referencing the name on the internal ledger with that shown on the bank statements, a significant scale fraud was detected and stopped.

Limitations

While this control is relatively simple, it can sometimes be difficult to construct. Firstly, it requires data from two points in the business process to be available so requires two good quality data sets to be made available in the same place for comparison. It also requires a detailed knowledge of the process and how to extract and compare those two data sets. Finally, it must be possible to join those two streams of data on a case-by-case basis so that we know for sure that we are comparing items that relate to one another. This creates the need for a common key (a piece of shared information). In the cheque fraud example, we could use the cheque number, in the “Orders placed Vs. Dispatched” example we have an order ID that is common - this is not always the case and can greatly complicate matters if not available.

The most significant limitation however is that the entire control is built on the assumption that process A is happening correctly in the first place. Consider the orders example again, if the order being taken is not recorded correctly in the orders system (say due to a new operator failing to enter it or a systems issue in the order placement system), neither of the 2 controls detailed here would highlight an issue at all as neither data would show the order. If used in isolation therefore, this type of control can lead to false confidence that everything is operating in control while significant errors go undetected and we need to look for these types of issues in a very different way.

Some Examples of Process Exception Identification Controls

· Dispatch Verification: An order has been placed but not dispatched within 3 days

· Payment Validation: A payment has been made successfully but the amount does not match the amount requested

· Data Protection / GDPR: A request to delete a customer’s data has been marked as complete yet there is still a record relating to the customer within a given system

· Fraud Detection: A cheque has been issued to one person or company and cashed by another

· Medication Validation: A patient has been issued medication that is not appropriate for any of her recorded conditions

First Published 30th December 2020

All views expressed in this article are solely those of the author

© Alex Cowhig 2020