An email arrives just before the payment run. A familiar supplier asks the team to use a new bank account, attaches a plausible letter and says the change is urgent. The invoice itself is genuine. The question is whether the new payment instruction is genuine too.
Treat that question as a separate control. Hold the affected instructions, verify the request through an independently trusted route and obtain an authorised decision before changing payment details. A clean invoice history does not establish the authenticity of a new account request.
Keep three decisions separate
A supplier bank change involves at least three decisions: whether the requester is legitimate and authorised, whether the supplier record should change, and whether a particular payment can be released.
Combining them into one approval creates a dangerous shortcut. Someone may approve an invoice because the goods arrived, while another person interprets that approval as permission to use the newly supplied account. The evidence supporting those decisions is different.
Singapore Police Force's May 2026 advisory addresses requests to update vendors' payment accounts. It recommends additional verification, including using a different communication medium, before acting on unusual payment instructions. The workflow below applies that preventive advice to a payment operation; it does not claim that any control eliminates fraud.
Make one supplier-maintenance owner responsible for coordinating the change. A designated verifier performs the independent check. An approver reviews the change evidence, and the payment approver checks the instruction that will actually be used. In a small team, arrange a second authorised person for the critical review rather than treating self-checking as independent approval.
Establish the contact route before discussing the account
The verifier should start from contact information the business already trusts, such as a previously validated supplier contact record. Do not rely on a telephone number, messaging account or link supplied in the change request itself.
Replying in the same email thread does not provide independent verification. The mailbox may be compromised, or a lookalike address may have been inserted into the conversation. A convincing signature and knowledge of an outstanding invoice are not sufficient proof.
A call to an established number can help, but the procedure must also confirm that the person reached has authority to validate the change. Ask them to confirm the request, relevant entity, account details and intended effective date through the organisation's approved verification process. Keep a record of who verified what and how the contact route was established.
Avoid turning the exercise into a request for banking passwords or access credentials. The purpose is to verify a business instruction. Any supporting account evidence should be handled through approved secure channels with access limited to those who need it.
If the established contact cannot be reached, the outcome is “not yet verified”. It is not permission to use a new contact offered by the requester or to let urgency substitute for evidence.
Read the diagram text
CURIOUSRUBIK SINGAPORE / PAYMENT CONTROLS The stop must survive every handoff Suspect a wider compromise? Escalate to security and reassess the scope of the hold. Request intake Preserve request evidence; identify affected instructions Hold affected instructions Designated verifier Use a previously trusted contact; confirm their authority Unreachable? Not verified. Keep the hold. Independent approver Review the verification evidence; accept or reject the change Record the permitted version and effective date Payment approver Compare the final instruction with the approved version Release only after required payment checks PROPOSED HANDOFFS · A SAME-THREAD REPLY IS NOT INDEPENDENT VERIFICATION curiousrubik.com
Use a change record that follows the affected payments
A practical checklist should include the request and the consequences of accepting it:
- Supplier legal entity and existing record identifier
- Request date, sender and preserved request evidence
- Existing payment-instruction version and proposed change
- Intended effective date and affected company entities
- Trusted contact source and how it was previously established
- Verification date, verifier, person reached and conclusion
- Independent approval, limitations and any unresolved question
- Affected invoices, prepared payment files and release status
- Confirmation that the approved version reached the final payment instruction
Mask sensitive account details in general status views. The authorised reviewer still needs sufficient detail to compare the approved change with the instruction being released. A status note saying “bank checked” is too weak if nobody can establish which account version was checked.
Preserve the previous version and history under the company's records and security policies. Do not overwrite the old details in a way that makes it impossible to reconstruct what a previous payment used.
Work out the scope of the hold
Consider a hypothetical Friday payment run. Supplier A has three invoices selected. A bank-change request arrives after the payment file was prepared but before release. Supplier B has a separate invoice in the same batch and no apparent connection to the request.
The team first identifies which instructions may be affected. It holds Supplier A's payments while checking both the supplier record and the prepared file. A file created before a record change may contain different details from the current supplier screen. Conversely, an automatic refresh may have already inserted the new details.
Supplier B's payment can continue only if the normal checks are satisfied and the incident assessment gives no reason to widen the hold. If evidence suggests a compromised payment process or broader mailbox issue, the responsible security and finance owners may need to expand the scope. “Unrelated” should be an assessed conclusion, not an assumption based on a different supplier name.
After verification, the approver decides the permitted instruction and effective date. The payment team checks whether the held file must be cancelled and recreated or handled through another approved process. It then compares the final instruction with the approved version before release.
Do not automatically pay the old account while the request is unresolved. A legitimate account closure or other issue could make that inappropriate. The payment owner should resolve the permitted route with verified supplier contacts and authorised internal reviewers.
Read the diagram text
CURIOUSRUBIK SINGAPORE / PAYMENT CONTROLS A prepared file can still need to change Hypothetical payment queue · Check the prepared file against the approved instruction version. SUPPLIER A A1 · Held A2 · Held A3 · Held SUPPLIER B · B1 Normal checks + incident scope assessment Change after file preparation Verify Decide permitted version Recreate / amend through approved process Final comparison The old account is not an automatic fallback. HYPOTHETICAL EXERCISE · DO NOT TREAT AN UNRESOLVED CHANGE AS VERIFIED curiousrubik.com
Plan for legitimate urgency
Some genuine changes will arrive late. The supplier may have failed to notify the business promptly, or an operational problem may make the existing account unusable. A sound process should allow escalation without removing verification.
Name the person who can coordinate an urgent review and the backup if that person is unavailable. Give them a concise evidence pack rather than a forwarded chain with a request to “please approve”. The decision should state what was verified, any residual concern and exactly which instructions it covers.
An urgent route should not let one person request, amend and release the change unchecked. If the business cannot complete its required verification before the run, keep the affected instruction held and manage the commercial consequence through trusted contacts. Record the reason and next action so the item receives attention rather than remaining indefinitely suspended.
If a potentially affected payment has already been released, activate the incident response promptly. This may require urgent bank contact and security escalation through established channels. Preserve relevant records and let the authorised incident owners coordinate further action; changing the supplier record alone does not address a payment already sent.
Automate the signals and preserve the stop
Automation can detect a change to payment details, flag requests near a payment run and identify invoices or prepared files using the affected supplier record. It can assemble prior verification history and prevent an unapproved version from entering a new instruction.
The stop must survive the entire route to payment. A hold in the supplier-maintenance queue is ineffective if someone can export an old spreadsheet, manually enter the new account and release it outside that queue. Review the practical bypass routes and ensure authorised exceptions still carry evidence and approval.
Keep human judgment over authenticity and authority. A matching name, document image or familiar wording may assist the verifier but should not be treated as proof. If automated checks fail or source data is unavailable, make that failure visible. A blank warning panel should not be mistaken for a successful check.
Test the process with a controlled exercise
Use fictional details and an internal simulation. Test a genuine-looking request, an unreachable established contact, a changed instruction after file preparation and a request affecting more than one paying entity. Do not send real funds or involve a supplier without the appropriate authority.
Measure how quickly the team identifies affected instructions, whether every release links to approved evidence, and how often urgent exceptions lack an independent reviewer. Record false alarms too: excessive noise can push staff towards informal workarounds.
Before the next payment run, ask one question: if a supplier's account changes after the file is prepared, who checks the account in the final instruction? If the answer is unclear, fix that handoff before adding more automated alerts.
