The control framework covers who may initiate a payment, who may approve it, who may transmit it to the bank and who reconciles afterwards. The requirement is that these are not the same person.

In mid-sized Riyadh businesses they often are, not through negligence but because the finance team is small and the arrangement grew gradually. The same single point of failure exists whether the company has five employees or five hundred.

Segregation of duties in practice

Perfect segregation is difficult in a small team, and the practical answer is compensating controls. Where one person must both create and transmit a payment, two things give meaningful protection: an independent review of the payment file against approved invoices before release, and a next-day reconciliation by someone else. The design fits the team that exists, not the one an ideal framework assumes.

Authority limits and approval hierarchies

Payment authority should be defined by value band and payment type, documented in a delegation of authority matrix and enforced in the system rather than by policy alone. A limit that exists only in a document is not a control, since the system processes whatever a user with the right permission submits, whatever the policy says.

Bank mandate management

Bank signatories and portal users need regular review, particularly after staff changes. Former employees can keep portal access after they leave, and mandates can list people who left long ago. A periodic mandate review in the control calendar is one of the highest-impact and lowest-effort controls available.

A hypothetical example

Consider a trading company whose finance manager creates supplier payments, holds the only bank portal credentials and performs the monthly reconciliation. The exposure is complete, and an unplanned absence would leave the business unable to pay suppliers or staff. The redesign adds dual authorization and a second credential holder.

Reconciliation and monitoring

Daily or, at minimum, weekly bank reconciliation is itself a detective control, since unexplained items surface fastest when reconciliation is frequent. Automated reconciliation through bank integration makes this practical at volume. The framework connects to wider internal control design and covers the kind of controls external auditors commonly test.

Testing controls instead of assuming them

A control framework that has never been tested is a document. Periodic walkthroughs try to process a payment above a limit, check that a former employee's portal access is revoked, and verify that someone other than the preparer performs the reconciliation. The aim is to find gaps before an auditor or an incident does. This sits within broader internal control design and is what makes automated banking safe to run at volume.

Documenting controls for whoever comes next

Controls that rely on unwritten practice disappear when the person applying them leaves. We document the delegation of authority matrix, payment procedures and reconciliation responsibilities so a new employee can follow them. Control failures often happen because a new person did not know the control existed.

Balancing control with speed of work

Controls that are too heavy push the team to work around them. If approving every payment takes days, the team starts batching payments or asking for exceptions, and both weaken control more than a reasonable upper limit would. We design controls to be the easiest path, because a control everyone bypasses is worse than none: it creates an illusion of protection.