Controls operations teams can live with
Most operational controls were added one at a time, each after something went wrong, by whoever was accountable that quarter. Nobody adds them up. The people performing the checks are usually the first to notice that some of them stopped checking anything a long time ago.
Take a refunds queue, with round numbers chosen only to show the shape of the problem. Say a payments team handles 400 refunds a day and every one needs a second person to approve it. At three minutes per approval, that is 20 hours of checker time a day, somewhere between two and three people doing approvals and nothing else. Now suppose most of those refunds are small, go back to the original card and match an existing transaction exactly. The second pair of eyes on those is buying very little, and it adds hours to a refund that a customer is already waiting for.
The answer is rarely to remove the control. It is to size the control to the risk and put it where the work already happens, then measure what it costs.
Every control exists to stop or detect a particular error or a particular fraud. So the first question about any control is which risk it addresses, written as one plain sentence. "Prevents a refund being paid to an account other than the original payment method" is a risk sentence. "Four-eyes on refunds" is a mechanism with no risk attached. If nobody in the room can write the sentence, the control is a candidate for retirement, and that is a conversation to have openly with risk and compliance, with the attempt at the sentence in front of you.
Once the risk is written down, the check can be sized to it. Refunds to the original card, below a limit and matched to a transaction, can pass automatically, with a system rule that blocks anything above the original amount. Refunds to a different destination, or above the limit, or with no match, go to a checker who now sees perhaps a tenth of the volume and can look at each one properly. The control gets stronger where it matters and disappears where it was doing nothing.
Build the check into the work
The controls people live with are the ones built into the workflow instead of bolted on afterwards as a separate review step. A few shapes are worth copying.
Validation belongs at the point of entry. The payment screen rejects an account number that fails its check digits and holds any amount above the operator's limit. It refuses a release submitted after the bank's cut-off. The error arrives while the person still has the context to fix it, which is when fixing it is cheapest.
Segregation has to be enforced by the system. If the tool allows a maker to approve their own item and the policy says they should not, the policy is decoration. The same applies to shared logins, which erase the whole control without anyone noticing. That one is worth auditing before any new control is designed.
The checker needs to see what they are checking. The approval screen should show the original transaction beside the request, with the difference marked, and reason codes from a list. A checker comparing two screens from memory is doing a slower job less well, and reason codes from a list turn the monthly reporting into a by-product of the check.
Evidence follows the same logic. When the approval happens inside the system, the log of who approved what, at what time, and what they were shown is the evidence. Screenshots pasted into a shared folder the week before an audit are a second job created by a control that lives outside the systems it governs. Spreadsheet-based checks have the same problem, and they carry the risks we described in the spreadsheet that runs your operation.
Controls also degrade, and the degradation is measurable. A four-eyes check at high volume tends to become a click. You can see it in two numbers: the median time an approval takes and the rejection rate. Approvals that take four seconds are not reviews. A check that has rejected nothing in 10,000 items is either guarding against a risk that has moved elsewhere or it is no longer being performed.
A check that has rejected nothing in a year is either guarding against nothing or no longer being done.
Limits deserve the same scrutiny. A threshold set three years ago against yesterday's average transaction now sends almost everything to a checker, which is the same as having no threshold at all. Pull the distribution of amounts once a year and set the limit where it separates the routine from the unusual, then write down who can change it.
Then cost the whole set. For each control, record the monthly volume, the average time per item, the delay it adds for the customer and what it caught in the last twelve months. Control time is staff time, so it belongs in your operational cost per transaction alongside everything else. In the refund example above, the checking time could easily exceed the cost of the refund itself, which is the kind of number that makes a redesign conversation short.
Regulated operations need maker-checker on payment release, on customer data changes and on anything that moves money outside agreed limits, and the controls that matter most should be the hardest ones to bypass. What they also need is a design that a person can perform properly at the pace the work arrives, with evidence that appears without anyone taking a screenshot.
A practical start: list the five controls that consume the most staff time. For each, write the risk sentence, the monthly volume, the average time per check and the date it last caught something. Take that list to your next risk committee and agree which to keep, which to redesign and which to retire. The ones with no recorded catch and no risk sentence usually make the decision easy.
Discuss your operations
