What dual authorisation means
Dual authorisation, sometimes called the four-eyes principle, means that no payment can be released by a single person. One user creates or prepares the payment. A second user, with the right authority, reviews and approves it. Only then does it go out.
The control works because it changes the odds for anyone trying to misuse the payment process. A fraudster now has to deceive two people, or one person has to collude with another. An honest mistake has two chances to be caught instead of one. And the person preparing payments knows their work will be checked, which tends to improve care at the first stage.
Dual authorisation is common practice in banking and in larger finance teams. It is just as valuable in smaller businesses, where one trusted person often handles everything from supplier set-up to payment release.
The fraud it is designed to stop
The fraud that dual authorisation most directly counters is business email compromise, often shortened to BEC. It takes several forms.
- Supplier impersonation. A fraudster gains access to a supplier's email, or registers a near-identical domain, and writes to the customer saying bank details have changed. The next invoice is paid to the fraudster.
- Executive impersonation. An email appears to come from a director asking finance to make an urgent, confidential payment, often for an acquisition or a legal settlement.
- Payroll diversion. An employee's email is used to ask HR or finance to change the account their salary or expenses are paid into.
- Insider fraud. A staff member sets up a fictitious supplier, or alters an existing one, and pays invoices to an account they control.
These schemes share features: urgency, secrecy, a change of bank details and reliance on a single person acting quickly. A second approver who is required to check the payment, and who is not under the same pressure, breaks that pattern.
An illustrative example
This scenario is invented but typical. An accounts assistant at a distribution company receives an email from a regular supplier. The message thread is genuine, because the supplier's mailbox has been compromised. It says the supplier has moved banks and attaches a letter with new details. The next invoice, for 64,000 dollars, is due this week.
Under single authority, the assistant updates the supplier record and pays. The money goes to a fraudster and is moved on within hours.
Under dual authorisation with separate control over beneficiary changes, the assistant can submit the change but cannot approve it. The finance manager sees a request to change bank details for an established supplier, with a new account in a different country. Company policy requires a call-back to a number already on file. The supplier's genuine accounts team confirms they have not changed banks. The fraud is stopped before any money moves.
Separation of duties
Dual authorisation is one part of a wider principle: separation of duties. The idea is that the key steps in a payment process are split between different people so that no individual controls the whole chain.
In a payment process, the main duties to separate are:
- Beneficiary maintenance. Creating new payees and changing bank details.
- Payment preparation. Entering payments or uploading batch files.
- Payment approval. Releasing payments for processing.
- Reconciliation. Checking what was paid against invoices and bank statements.
- User administration. Adding users and assigning rights in the payment system.
In an ideal set-up, a different person handles each. In a small team that is not always possible, but the most important separations are achievable with two people: the person who prepares payments should not approve them, and the person who changes beneficiary details should not be the only one to approve payments to the changed account. User administration should sit with someone senior who does not process payments day to day.
Designing user roles
Most business payment platforms let you assign roles to users. Typical roles include:
| Role | Can do | Cannot do |
|---|---|---|
| Viewer | See balances, payments and reports | Create or approve anything |
| Preparer | Create payments and upload files | Approve their own payments |
| Approver | Review and approve payments within a limit | Approve payments they created |
| Beneficiary manager | Submit new payees and changes | Approve their own payee changes |
| Administrator | Manage users and permissions | Ideally, release payments |
Give each user the narrowest role that lets them do their job. Review roles when people change jobs or leave. A departed employee whose access was never removed is a weak point that auditors and fraudsters both look for.
Setting approval limits
Limits let you match the level of scrutiny to the size and risk of a payment. A common structure has tiers.
- Routine payments below a modest threshold need one approver in addition to the preparer.
- Payments above that threshold need an approver with a higher limit, such as the finance manager.
- Very large payments need two approvers, one of them a director.
- Any payment to a new beneficiary, or to a beneficiary whose details changed recently, needs senior approval regardless of amount.
Set the thresholds based on your normal activity. If most supplier payments are under 20,000 dollars, a threshold of 25,000 means the higher tier is reserved for genuinely unusual payments. If the threshold is set too low, senior approvers see so many payments that they stop looking closely, which defeats the purpose.
Watch for payments split to stay under a threshold. A batch of several payments to the same beneficiary, each just below a limit, should be treated as one payment for approval purposes.
What an approver should actually check
Dual authorisation only works if the second person really reviews the payment. Clicking approve on a screen full of payments without reading them provides little protection. Give approvers a short, specific checklist of points to confirm before they approve.
- The beneficiary is known and the bank details match the ones on file.
- Any recent change to the beneficiary's bank account was verified by call-back.
- The amount matches the invoice or agreement.
- The purpose makes sense for this beneficiary.
- No unusual urgency, secrecy or pressure is attached to the request.
- Any new country or currency for this beneficiary has a clear explanation.
An approver who has any doubt should hold the payment and ask. A delayed genuine payment costs little. A released fraudulent one can cost a great deal.
Controls that support dual authorisation
Dual authorisation is strongest when combined with other safeguards.
- Call-back verification of any change to bank details, using a phone number already on file.
- Scheduled payment runs, so payments are prepared and approved in a planned window rather than on demand.
- An audit trail that records who created, changed and approved each payment and payee, with times.
- Strong authentication for every user, including multi-factor sign-in.
- Training on recognising email compromise, with a clear rule that urgent requests by email alone are never enough.
- Regular reconciliation by someone independent of payment preparation.
The guide to payment returns and recalls explains why recovering a fraudulent payment is so difficult, which is the strongest argument for prevention.
Making it work in a small team
Small businesses sometimes feel dual authorisation is impractical. It need not be. With two people, one prepares and the other approves. With one finance person, a director can act as approver on a mobile device. Scheduling payments for fixed days makes it easy for an approver to set aside time. Where there is a genuine emergency, the right response is to reach the approver by phone and keep the control in place.
Delegation needs planning too. Before holidays or busy periods, decide who will approve in each person's absence and set that up in the payment system in advance, with an end date. Avoid sharing log-in details or authentication devices so that one person can act as two. Shared credentials destroy the audit trail and make the second approval meaningless, and they are one of the first things an investigator looks for after a loss.
Testing that the control works
Controls drift. People cover for absent colleagues, temporary permissions become permanent, and a workaround agreed for one urgent payment quietly becomes normal practice. A control that looked sound when it was designed can be hollow a year later. Test it periodically.
- Review user rights. List every user of each payment system and their role and limits. Remove leavers, reduce rights that are wider than needed, and confirm no single person can both create and approve.
- Sample approved payments. Pick a handful of payments from the last quarter and trace them: who created each one, who approved it, how long the approval took and whether the supporting document was on file. Approvals that take seconds for large amounts may suggest approvers are not really reviewing.
- Sample beneficiary changes. For each bank detail change in the period, check that a call-back was made and recorded, and that someone other than the requester approved it.
- Run an exercise. Some businesses send a simulated fraudulent change request, with management's knowledge, to see whether staff follow the call-back rule. The results are usually instructive.
Use the audit trail for this work. A good trail shows each action, the user and the time, which turns a control review from a matter of memory into a matter of record. Share the findings with the team, without blame, and adjust roles, limits or training where gaps appear.
General information
This article is general information about payment controls and is not legal, audit or security advice. The right control design depends on your business and its risks. CCYFX Online supports dual authorisation, user roles, scheduled payments and an audit trail; the platform page describes how they work.
