Three properties that separate a control from a task list
- Separation of duties. The person who proposes an action is not the person who approves it, and the system refuses to let them be.
- Versioned rules. The rule that applied when the item was worked is recorded on the item, not inferred from today's configuration.
- Complete evidence at the time of work. Attachments and rationale are collected while the item is open, not reconstructed at quarter end.
Where maker-checker belongs
| Action | Maker | Checker |
|---|---|---|
| Write off an unmatched item | Operations analyst | Team lead, with a reason code |
| Reverse a duplicate posting | Operations analyst | Second analyst or lead |
| Change a matching tolerance | Process owner | Head of operations |
| Change a routing target | Process owner | Head of the receiving team |
| Dispose of a compliance case | Analyst | Compliance reviewer |
| Certify an account | Preparer | Reviewer, never the preparer |
SLAs that mean something
An SLA on a compliance queue is only useful if breaching it is visible before the breach matters. Bankautomation ages every item from the event that started it, not from when someone opened it, and escalation is a state change rather than an email somebody might read.
The evidence pack
For a period and a scope, the export contains the items, their classifications, every action with its actor and timestamp, the approvals, the attachments and the rule versions in force. It is one action because assembling evidence by hand is exactly the work that makes teams cut corners under pressure.
Designing an approval chain that people will not route around
Every control that is more painful than the work it governs gets bypassed, usually with good intentions and a plausible reason. An approval chain that survives contact with a busy month end has three properties: it is proportionate to the risk of the action, the approver has enough context to decide without asking questions, and the path for a genuine emergency exists and is recorded rather than improvised.
- 01Scale the chain to the action. A write-off of a small item and a change to a matching tolerance are not the same risk and should not require the same number of approvals.
- 02Give the approver the case. An approval request that shows only an amount will be approved on trust. One that carries the item, its history, the proposed action and the reason gets a real decision.
- 03Make the emergency path real. A documented break glass route, with a mandatory reason and an automatic post-event review, is safer than a chain nobody can satisfy at 11pm.
- 04Escalate on time, not on memory. An approval that sits unactioned should escalate by itself, because a queue that depends on somebody remembering is not a control.
Segregation of duties, in the system rather than the procedure
Most policies state that the proposer and the approver must differ. Whether that holds in practice depends entirely on whether it is enforced by software or by a sentence in a document. The system version is unambiguous: the approve action is not available to the person who proposed, regardless of their permissions, and the attempt is logged. The procedural version depends on a busy person choosing correctly under deadline pressure, which is a weaker control than it appears in a policy review.
Role design supports this and is worth doing carefully once. Preparer, reviewer, approver and read only, scoped by account, entity and process line, covers the overwhelming majority of cases. The temptation to create bespoke roles per team produces a permission model nobody can explain, which becomes its own audit finding.
Age, SLA and breach are three different numbers
| Mechanism | What it measures | What it should trigger |
|---|---|---|
| Age | Time since the event that started the clock | Visibility, always, on the first screen |
| SLA threshold | Age against an agreed target for that item type | Escalation before the breach, not after |
| Breach | Target exceeded | A recorded exception with an owner and a reason |
| Backlog trend | Population age distribution over time | A capacity or process conversation, not an individual one |
The distinction that matters is between age and SLA. Age is a fact about an item. An SLA is a promise about a class of item. Reporting only breaches hides a population that is aging steadily inside its target and will breach together, which is the failure mode that surprises people.
One vocabulary across two floors
Operations and compliance are usually run as separate worlds with separate tools, and the work has the same shape in both: an item that needs a decision, an owner, an age, a required evidence set and an approval. Running both on one vocabulary has practical effects beyond tidiness. A team lead can read either queue without translation. Reporting to a risk committee aggregates rather than being assembled. And a control improvement made on one floor is immediately available on the other, instead of being rebuilt.
What to automate first
Start with the action that carries the most risk and the least structure today, which in most banks is either a write-off or a tolerance change. Both are usually approved by email. Moving one of them into an enforced chain with a reason code and a versioned record takes very little configuration and changes what an auditor finds. Once that pattern exists, extending it to the rest of the action list is repetition rather than design.
The same mechanics run reconciliation exceptions, which is why the operations floor and the compliance floor can share one vocabulary. See exception management for the engine and security and compliance for the control detail.
Questions about compliance workflow automation
Can approval chains have more than two steps?
Yes, chains are configured per action type and can depend on amount, account or risk. The constraint the system enforces is that a person cannot approve their own proposal.
What if we need a break glass path?
Emergency actions can be permitted for named roles, and every use is flagged, logged and surfaced in a report specifically so it can be reviewed rather than quietly relied on.
Does automation weaken our control environment?
It changes where the control lives. A tolerance applied by a person 200 times a day is not a control, it is a habit. The same tolerance, approved and versioned, applied consistently and reported on, is one.
Can we model our own workflow states?
Queues, states, required evidence and approval chains are configuration. What is not configurable is the ability to switch off the audit trail.