Bank detail change fraud costs companies millions in lost funds every year. A well-crafted email, a fake change-of-bank instruction, and the payment goes to a fraudulent account. Yet the real question is not about training staff (though that helps), but about designing application-level controls that make this fraud impossible to execute, without paralyzing operations.
This article is for CFOs, treasurers, and internal auditors who must ensure no payment can leave the company to a bank account that has not been formally validated, while preserving fluidity for legitimate cases (second account, genuine change, one-off mandate).
Bank detail change fraud from the system perspective
The typical fraud follows this pattern: a scammer sends an email impersonating a regular supplier, with a new bank account and an urgent update request. The accounts payable clerk receives the request, updates the vendor record in the ERP, and the next payment goes to the fraudulent account. The company discovers the scam two weeks later when the real supplier chases the unpaid invoice.
From the system perspective, the problem is simple: a vendor's bank details are sensitive data that determine the final recipient of each payment. Changing this data without control is equivalent to authorizing payment to any account. The consequences extend beyond direct financial loss: CFO liability, trust breach with the vendor, internal audit, criminal complaint, crisis communication.
In 2025, a large distribution company in Morocco lost MAD 480,000 in three successive transfers to a fraudulent account. The audit revealed that details had been changed five times in two months, always by the same person, without any formal validation. The system allowed changes without restriction.
Attach an account to a validated vendor record, once
The first control principle is unique attachment: each bank account must be attached to a validated vendor record once, at creation time or during a formally approved change. This attachment must include a complete audit trail: who requested the attachment, who validated it, when, on what documentary basis (original bank details, bank certificate, telephone confirmation).
In a properly configured ERP, bank details are not a simple text field editable at any time. They are a separate entity with their own lifecycle: pending validation, validated, suspended, archived. Each status change generates a line in the audit table. Creating a new bank account for an existing vendor triggers a validation workflow, with notification to the treasurer or procurement manager.
Concretely, this means that entering a new bank account (IBAN, BIC, account holder) in the vendor record is not enough. The system creates an attachment request, in "pending validation" status, and blocks all payments to this account until validation is obtained. The previous account remains active until the new one is approved.
Technical configuration example for an ERP or procurement system: supplier_bank_accounts table with columns account_id, supplier_id, iban, status (pending, validated, suspended), validated_by, validated_at, supporting_document_id. The application constraint prevents any payment record (payment table) whose recipient_account_id points to an account in status other than validated.
The lock: forbid all payments to unattached accounts
The application lock is the second principle: no transfer can be executed to a bank account that is not attached to a validated vendor record. This lock must be technical, not procedural. It is not enough to ask clerks to check the status, the system must physically refuse the operation.
In practice, this translates to a foreign key constraint or a business rule at the payment engine level. When creating a payment order, the system verifies that the beneficiary account is in the list of validated accounts for the vendor concerned. If the account is in "pending" or "suspended" status, the payment is automatically rejected with an explicit error message: "Beneficiary account not validated, transfer impossible."
This lock protects against the two most common fraud vectors: direct modification of bank details in the vendor record (the new account not being validated, no payment goes through), and creation of a fake vendor with fraudulent bank details (the record must be validated before any payment, which triggers usual checks on the third party's actual existence).
A well-designed system also offers real-time visibility: a treasury dashboard displays the number of accounts pending validation, with age and amount of blocked invoices. This allows the CFO to manage validations without slowing payments.
The real issue: exception procedure for legitimate cases
The strict lock creates an operational constraint: how to process legitimate detail changes, adding a second account for a vendor diversifying their banks, or one-off payment to a different account (mandate, subcontractor)?
The answer is a formalized exception procedure, which defines three elements: who can request the exception, who must validate, and what proof is required before release. Without this procedure, the lock becomes an obstacle that teams bypass (entering a fake vendor, manual database modification, temporary control deactivation), and the risk returns through the back door.
Typical cases requiring an exception:
- Second bank account: the vendor opens an account at a new bank and requests payment split. Required proof: original bank certificate, signed and stamped, confirming the account belongs to the vendor.
- Bank change: the vendor closes their old account and transfers operations. Required proof: written notification from the vendor, accompanied by the new bank details, plus a callback to the vendor's accounting department to confirm.
- Mandate or subcontractor: the vendor requests payment to a third party (subcontractor invoice, debt settlement). Required proof: mandate letter signed by the vendor, identifying the beneficiary and amount, plus written validation from the internal order giver.
Each exception must follow the same workflow: formal request with supporting documents, validation by a person different from the one who received the request (segregation of duties), recording in the system with reference to documents, notification to the treasurer. The account remains pending validation until all proofs are provided.
Who validates a change, and why never the person who received it
Segregation of duties is the fundamental principle of all anti-fraud controls. The person who receives a bank detail change request must never be the one who validates the change in the system. If this is the case, a simple fraudulent email is enough to bypass the control.
Recommended organization for a large enterprise:
- Requester: accounts payable clerk, buyer, or administrative manager who receives the change request.
- Level 1 validator: procurement manager or management controller, who checks the request's consistency with the vendor file (payment history, current contracts, upcoming amounts).
- Level 2 validator: treasurer or CFO, who validates the new account release after receiving documentary proof and the callback.
In medium-sized companies (50-200 employees), where roles are sometimes combined, it is acceptable for the procurement manager to be both requester and level 1 validator, provided an independent level 2 validator (CFO or internal auditor) approves all changes before activation.
A properly configured system does not allow a user to validate a request they created themselves. The authorization matrix in the ERP must reflect this segregation: "Requester" profile with entry rights, "Validator" profile with approval rights, and mutual exclusion of both rights for the same person.
Callback and proof: what the system requires before release
The callback is the final security brick before validating a detail change. It consists of calling the vendor on a known number (the one recorded in the vendor file, not the one in the received email) and confirming the request with the accounting department or manager.
Structured callback procedure:
- Retrieve the phone number from the vendor file, or from the company's official website (contact section or legal notice), never from the request email.
- Call the vendor's accounting department and request confirmation of the bank detail change. Note the contact's name and call time.
- Request sending of original bank details by post or email from an official vendor address (verifiable domain).
- Check consistency between details received by callback and those provided in the initial request. Any discrepancy triggers immediate rejection.
- Record the callback trace in the system: date, time, contact, verification result.
The system must require entry of this information before allowing final account validation. A mandatory "Callback reference" field in the validation workflow, with date and name of the person contacted at the vendor, ensures the step is not skipped.
Examples of acceptable supporting documents for a bank detail change:
- Original bank certificate: official document from the vendor's bank, confirming the account holder and IBAN. Must bear bank stamp and signature.
- Business registration extract or incorporation certificate (for new vendors): allows verification of the company's legal existence and cross-checking with bank detail information.
- Copy of a voided check: some companies provide a crossed check bearing the "voided" mention, with printed bank details, as account proof.
- Letter signed by the legal representative: for bank changes, a letter signed by the manager or CEO, accompanied by the new bank details, constitutes acceptable proof.
Each document must be scanned and archived in the vendor's electronic file. The archiving policy must provide for a minimum retention period of five years (criminal prescription period for fraud in Morocco).
Audit trail of a bank detail change
Internal audit or the chartered accountant must be able to reconstruct the complete history of a bank detail change from the system. This audit trail must include:
- Request date: when the change was entered in the system.
- Request author: name of the user who created the new account attachment request.
- Successive validators: list of people who approved the request, with date and time of each validation.
- Supporting documents: reference to scanned files (bank details, certificate, mandate letter).
- Callback: written trace of the telephone verification (date, contact, result).
- Old and new account: previous and current IBAN, with switchover date.
- First payment to new account: date and amount of first transfer executed after validation.
This trail must be kept in a timestamped audit table, non-modifiable by ERP users. Each line records an event (creation, level 1 validation, level 2 validation, activation, suspension), with user and timestamp. In case of fraud, the auditor can retrace the complete path of the fraudulent request and identify the failure point (absence of callback, validation by same person, missing supporting document).
A standard audit report could list all bank detail changes over the last twelve months, with a compliance indicator for each case: green if all proofs are present, orange if a document is missing, red if validation was done by the requester or if no callback is recorded. This report allows the CFO to manage process compliance and identify drift before it causes a loss.
Five questions to ask a software vendor on this specific point
If you are considering deploying an ERP or procurement management solution, here are five questions to ask the vendor to assess the robustness of bank detail control:
1. Does the system allow blocking payment to a bank account that is not validated?
Expected: yes, through a mandatory and non-deactivatable business rule. The system must technically refuse all transfers to an account in "pending" or "suspended" status.
2. Can a validation workflow be configured with segregation of duties?
Expected: yes, with at least two distinct validation levels, and prohibition for a user to validate a request they created themselves. The authorization matrix must allow this segregation.
3. Does the system maintain a complete audit trail of bank detail changes?
Expected: yes, in a timestamped and non-modifiable table, with recording of each event (request, validation, activation). Export possible for external analysis.
4. Can scanned supporting documents be attached to each change request?
Expected: yes, with possibility to make certain document types mandatory before validation (bank details, bank certificate, mandate letter). Files must be archived in the vendor file.
5. Does the system offer a dashboard of accounts pending validation?
Expected: yes, with real-time visibility of the number of pending requests, age, amount of blocked invoices, and possibility to filter by vendor or requester.
If the vendor answers no to one of these questions, ask to see the development roadmap or consider an alternative solution. An ERP that does not control third-party bank details exposes the company to major financial and criminal risk.
To go further, you can consult our digital consulting services or explore our system integration solutions in Morocco, which include auditing your internal control processes and configuring workflows adapted to your organization.
FAQ
How to detect that a bank detail change request is fraudulent?
Several warning signs: urgent request without explanation, email from a slightly different address than usual (typo in the domain), bank details to a foreign bank when the vendor is local, no response to callback on the known number, inconsistency between the account holder name and the vendor's business name. When in doubt, suspend the request and ask for written confirmation from the vendor's legal representative, sent from an official address.
What to do if the vendor refuses to provide a bank certificate for a bank detail change?
A legitimate vendor always agrees to provide a bank certificate or equivalent supporting document. If the refusal persists, offer an alternative: sending bank details by post with manager signature, or callback with written confirmation sent from the official email address. If none of these solutions are accepted, maintain payments to the old account until regularization, explaining that your internal control policy requires it.
Can the callback be automated to save time on bank detail changes?
No, the callback must remain manual. Automated telephone verification systems (IVR, voice recognition) are easily bypassed by a fraudster who has access to the vendor's number. The human callback allows asking open questions (amount of last invoice, name of procurement manager at your company, reference of last signed contract) to confirm that the contact is indeed a member of the vendor company. This manual step takes five minutes and prevents losses of several hundred thousand dirhams.
How long should supporting documents for a bank detail change be kept?
In Morocco, the criminal prescription for fraud is five years from discovery of the facts. It is therefore recommended to keep supporting documents (bank details, bank certificate, callback trace, vendor letter) for at least five years after the detail change. For accounting and tax audit purposes, a ten-year period is preferable, aligned with accounting document retention.
What to do if a fraudulent transfer has already left to an unvalidated account?
Act immediately: contact the issuing bank to attempt a funds recall (effective only in the first hours), file a complaint with the National Brigade of the Judicial Police (BNPJ) or gendarmerie, inform the real vendor so they confirm the fraud in writing, freeze the fraudulent account via a judicial request if the account is in Morocco, and launch an internal audit to identify how the control was bypassed. Also inform your insurer if you have cyber-risk or computer fraud coverage.