Ask AwraIQ about features, pricing, onboarding, login, integrations, security, demos, mobile apps, automation, reports, or support.
Procurement · Payment security
A supplier’s bank details change only when a second person approves it.
Turn on one Procurement Default and every edit to where a supplier is paid — bank account, bank, M-Pesa number, paybill or till — is held as a pending change. Someone else who can approve vendors decides it, payments keep going to the details already on file until they do, and once the details change the supplier is emailed at the address on their record.
Opt-in per workspace · Requester cannot approve · Old details stay in use while pending · Supplier notice on every change · Web and mobile
Held
Payment details change Waiting for approval
Asked by Joy K., 28 Oct 2026 09:14. Payments keep using the current details until it is approved.
Bank account number ••••••••4471 ••••••••9032
Bank 12 57
Approve change Reject
Joy sees no Approve button here. She asked for the change, so someone else with permission to approve vendors must decide it.
Two peoplethe person who typed the new details can never be the one who approves them
Old detailsstay on the supplier, and on every payment, until the change is approved
Always toldthe supplier is emailed when their details change — a security notice with no off switch
Last fouraccount and phone numbers are masked to their last four digits on the change, the notice and the log
One fraud attempt, both sides of the screen
The fraudster writes the email. They do not get to approve the change, or stop the notice.
Payment diversion rarely needs a hacked system. It needs one convincing email to the person who keeps supplier records, a few days before a large invoice is due. Here is that email, and what your workspace does with the edit it asks for. Names, addresses and numbers are illustrative.
What lands in Accounts’ inbox
Please find attached invoice SOS-2214 for the October stationery order, KES 486,200, due 31 October.
SO
Savanna Office Suppliesaccounts@savanna0ffice.example
27 Oct Good morning. Our bank account is under audit this month, so please update our details before paying SOS-2214. New account ending 9032 — the letter on our letterhead is attached.
Kindly confirm once done, as the auditors need it today.
Change_of_bank_details.pdfSame thread, same name, one character different in the address, and a deadline. Nothing here would stop a busy person.
Thanks, I have updated your details on our side.
What the workspace does with Joy’s edit
On the supplier’s page, 28 Oct 09:14
Bank account number ••••••••4471 ••••••••9032
Joy’s save reads “Vendor updated. The change to their payment details needs a second person to approve it before it is used.” Everyone else who can approve vendors gets it in their notification bell.
If SOS-2214 is paid today, it is paid to the account ending 4471 — the supplier record has not changed.
Daniel, the finance manager, opens the change, does not recognise the reason, and phones Savanna on the number from their contract rather than the one in the letter. They have changed nothing. He rejects it. The current details stay in use, and the rejection is in the audit log.
And if it had been approved
Security notice Your payment details were changed
Mto Water Trust has changed the details it uses to pay you. Future payments go to the details below.
If you did not ask for this change, contact Mto Water Trust straight away using contact details you already trust — not a number in an email you were sent.
Bank account number: ••••••••4471 → ••••••••9032
The notice goes to the email on the supplier record, not to the address the request came from — the fraudster’s reply-to never sees it. It is sent whenever new details are applied, with the second-approver switch on or off.
The rules of the hold
Seven rules, all enforced on the server.
These hold whichever screen the edit came from, because the web form and the mobile app both hand payout fields to the same service rather than writing them onto the supplier.
01
Six fields are payout fields
Bank account number, bank, M-Pesa phone, M-Pesa paybill, paybill account and M-Pesa till. Name, address, phone and tax details save as usual; only these six are held.
02
Anyone who can edit suppliers can ask
A change is requested by editing the supplier, which needs edit_vendors. Only fields whose value actually differs become part of the change; a save that leaves them alone creates nothing.
03
Someone else approves
Approving needs approve_vendors, and the person who asked is refused even when they hold it: “You asked for this change, so someone else must approve it.”
04
Payments use the old details meanwhile
A held change is stored beside the supplier, not on it. Pay screens and payment runs read the supplier record, so they keep paying the details on file until the change is approved.
05
The newest edit wins
A second edit while one is waiting marks the older one superseded, so approving it later cannot put back details someone has since corrected. Each change is decided once.
06
The supplier is told
When new details are applied, the supplier is emailed, listing each field’s old and new value masked — at the address on their record and, when the same save changed that address, at the one it replaced. There is no setting that turns it off.
07
Every step is logged
Requested, changed and rejected each write an audit entry naming the supplier and the masked before-and-after, alongside who asked and who decided on the change itself.
Off by default, one switch to turn on
Every workspace gets the notice. You choose whether to add the second person.
The second approver is an opt-in Procurement Default, set per workspace — some small teams have only one person who touches supplier records. The supplier notice is not part of that choice.
Switch off — the default
The edit applies on save
- Someone with permission to edit suppliers changes a payout field.
- It is recorded as a change and applied straight away, noted as needing no second approver.
- The audit log records the masked old and new values.
The supplier is emailed that their details changed.
Switch on
The edit waits for someone else
- The same edit is held as a pending change; the supplier record is untouched.
- Everyone else who can approve vendors is notified, and the request is logged.
- One of them approves it — or rejects it, and the current details stay.
- On approval the new details are written to the supplier and logged.
On approval the supplier is emailed that their details changed.
A change to a supplier’s bank or M-Pesa details needs a second person The edit waits until someone else who can approve vendors approves it; payments keep using the old details until then. Either way the supplier is emailed when their details change. Settings → Procurement Defaults, as it reads in the product.
The record it leaves
An auditor can read the whole attempt without seeing a full account number.
Three audit actions under the Vendors module, each with a plain-language description. The change itself keeps who asked, who decided, when, and its final status: pending, approved, rejected or superseded.
Audit log · Vendors Illustrative rows from the attempt above
| When | Action | Description |
|---|---|---|
| 28 Oct 09:14 | vendor_payout_change_requested | Change to Savanna Office Supplies’s payment details requested: Bank account number ••••••••4471 → ••••••••9032; Bank 12 → 57. |
| 28 Oct 11:02 | vendor_payout_change_rejected | Change to Savanna Office Supplies’s payment details rejected: Bank account number ••••••••4471 → ••••••••9032; Bank 12 → 57. |
| — | vendor_payout_changed | Written instead when a change is applied, with the same masked summary — and that is the moment the supplier is emailed. |
Every way in
A control is only as good as the door it does not cover.
The supplier form
Editing a supplier on the web sends payout fields through the hold. The pending change shows at the top of the supplier’s page with Approve and Reject for those who may decide it.
HeldThe mobile app
The supplier edit screen shows what is on file, masked, and sends new values through the same hold. Approvers approve or reject a pending change from the supplier’s screen.
HeldThe developer API
The public write API refuses payout fields on a supplier outright. Where a supplier is paid is changed in the product, where a second person can be required and the supplier is told.
RefusedOutbound webhooks
Webhook payloads never carry the six payout fields, whatever the event — a receiving URL is whatever someone typed into a form.
WithheldSupplier details in the app
The app’s supplier view returns payout details masked to the last four digits of account, phone and paybill-account numbers.
MaskedThe approvers’ bell
A held change notifies everyone who can approve vendors except the requester, and has its own row in notification settings.
NotifiedWhat AWRA OpsHub does today
- A second-approver switch in Procurement Defaults, off by default and set per workspace, covering bank account, bank, M-Pesa phone, paybill, paybill account and till.
- A pending change held beside the supplier, so payments keep using the details on file until it is approved.
- The requester refused as approver, with approval limited to people holding permission to approve vendors.
- A newer edit superseding a waiting one, so an older change cannot be approved over a correction.
- A security email to the supplier at the address on their record whenever new details are applied, with old and new values masked, on every workspace.
- The previous address told too when the supplier’s email is edited in the same save as their payment details, so whoever typed the new address is not the only one who hears.
- A bell notice to the approvers when the supplier has no email on record, asking them to confirm the new details by phone.
- Audit entries for requested, changed and rejected, each with the masked before-and-after.
- Bell notifications to every other approver, with a row in notification settings.
- Request, approve and reject in the mobile app, over the same service as the web.
- Payout fields refused on the developer write API and withheld from outbound webhooks.
More we can add to your workspace
- Supplier-initiated changes from the vendor portal, submitted by the supplier and confirmed by your approver.
- A cooling-off period after approval, during which new details cannot yet be paid.
- A call-back checklist on the change, recording who phoned the supplier, on which number and what they said.
- Bank account name verification, matching the account holder’s name to the supplier before approval.
- A dashboard of recent payout changes across all suppliers, for a monthly review.
Where we point you to a specialist
- We will not judge whether a change is genuine. The control makes sure two people look and the supplier hears about it; confirming the request with the supplier on a number you already trust is the step that catches fraud, and it stays with your team.
- We will not guess a supplier’s address. With no email on their record the supplier is not emailed; your approvers are told instead, and the confirmation is a phone call only you can make.
A cooling-off period and a recorded call-back are the two items in that middle column that move this control closest to what insurers and auditors ask for. Tell us how your team verifies a bank change today, and we will come back with a written spec, a timeline and a price.
Around the payout record
The rest of the path from a supplier to a payment.
Vendor paymentsThe payments and payment runs that read the details this control protects. Supplier bills and payablesThe bills, due dates and aging that decide when a supplier is paid. Approval rules and delegationValue-based approval for requisitions, orders and payments, configured per workspace. Approve from a notificationDeciding approvals from the phone, where the second approver often is. Vendor portalWhere suppliers see orders, submit bills and keep their own profile. Security operationsAudit logs, sign-in controls and the trail this control writes into. Governance and rolesWho holds edit vendors and approve vendors, and how to keep them apart.
Frequently asked questions
Which supplier fields does the control cover?
Six payout fields: bank account number, bank, M-Pesa phone, M-Pesa paybill, paybill account and M-Pesa till. Other supplier details such as name, address, phone and tax PIN save as usual.
Who can request a change and who can approve it?
Anyone with permission to edit suppliers can request one by editing the supplier on the web or in the mobile app. Approving needs permission to approve vendors, and the person who asked for the change is refused as its approver even if they hold that permission.
Is the second approver on by default?
No. It is a Procurement Default that each workspace turns on, because some small teams have only one person who maintains supplier records. With it off, a change applies on save and is still audited, and the supplier is still emailed.
What happens to payments while a change is waiting?
They keep going to the details already on the supplier. A pending change is stored beside the supplier rather than on it, so pay screens and payment runs read the old details until someone approves the new ones.
Can the supplier email be switched off?
No. Whenever new payment details are applied, the supplier is emailed at the address on their record with each changed field’s old and new value, masked to the last four digits. It is a security notice rather than a preference, so there is no setting for it. When the same save changed their email, the address it replaced is emailed too. A supplier with no email on their record is not emailed; the people who approve supplier changes get a bell notice asking them to confirm by phone.
What happens if someone edits the details again while a change is pending?
The newer edit replaces the waiting one, which is marked superseded. That stops an approver later applying details someone has already corrected.
What is recorded in the audit log?
A request, an applied change and a rejection each write an entry under the Vendors module with the supplier’s name and a masked before-and-after for every field. The change itself also keeps who requested it, who decided it, when, and its status.
Can payout details be changed through the API?
The mobile app’s API sends them through the same hold as the web form. The public developer write API refuses payout fields on a supplier, and outbound webhooks never include them.
Help Center
Need a quick answer while you read?
Run inventory, procurement, assets, sales, and field work with approved AWRA guidance for setup, migration, integrations, security, pricing, and support.