Payment file fraud controls: protect bulk payroll and supplier files before upload

A payment file can move hundreds or thousands of payments in one upload, which makes it efficient and dangerous. Fraud or error at file-generation stage can bypass individual payment review, so finance should control the source data, file creation, transfer and bank approval as one end-to-end process.

Protect the supplier and payroll data before the file is built

A clean bank file cannot correct fraudulent beneficiary details already inserted into payroll or accounts payable. Verify new and changed bank details through a trusted process before the payment run.

Lock master-data changes during the final payment-run review where practical. Produce a change report for new beneficiaries and changed account numbers.

Separate file creation from final approval

Use maker-checker control so the employee creating the file cannot be the only person releasing it at the bank. The approver should see total amount, payment count and material exceptions.

For large batches, review high-value and first-time beneficiaries individually while using aggregate controls for the rest.

Protect the file from modification after approval

Use secure system-generated files and transfer channels. Where technology supports it, use hashes, digital signatures or controlled system handoff so finance can confirm the uploaded file is the one that was approved.

A spreadsheet exported to a shared folder and manually edited before upload creates a weak control boundary.

Set bank-side limits and dual approval

The bank should enforce user limits, payment-type permissions and multiple approval for material files where the service supports it.

Internal approval without bank-side enforcement can fail if a compromised credential belongs to a user with unrestricted release authority.

Use unique batch identifiers and status checks

Outages and timeouts can cause employees to upload the same file twice. Give every batch a unique identifier and check the bank status before resubmitting.

Reconcile payment count as well as value. Two files can have the same total while paying different beneficiaries.

Have a response plan for a compromised file

If fraud is discovered, contact the bank immediately with batch ID, beneficiary and amount. Preserve the original approved file and the version actually transmitted.

Review master-data access and user credentials before the next payment run. One fraudulent file can indicate a broader compromise of finance systems.

Worked example: an accounts-payable file contains 1,200 suppliers and £4.8 million of payments. One fraudulent bank-detail change for a £240,000 supplier can hide inside the total. The approver therefore needs exception reporting for new payees, changed accounts and unusually large payments rather than checking only that £4.8 million matches the ERP total.

Restrict manual edits after file generation. If an emergency change is required, regenerate the file from the approved source system or create a separately approved manual payment. Editing account numbers directly inside the payment file breaks the audit trail between supplier master data and bank execution.

Periodically test the control by tracing a sample from invoice approval through supplier master, file line, bank approval and statement debit. End-to-end testing can reveal that each individual system looks controlled while one unmonitored spreadsheet or shared folder sits between them.

Use bank-account validation and Confirmation of Payee where available before master data becomes approved. File-level controls are strongest when they sit on top of verified beneficiaries rather than trying to detect fraud only at the final upload stage.

Set an escalation threshold for control-total changes. If a normal supplier run is £1.2 million and today's run is £3.8 million, the file can still be correct, but the approver should receive an explanation of acquisitions, tax, annual contracts or other drivers before release. Large variance is a risk signal even without an obvious fraudulent line.

Review out-of-hours activity. A file uploaded at 2am by a user who normally works 9am to 5pm should trigger investigation even if the amount is within limits. Behavioural alerts can complement traditional maker-checker controls.

Keep payment-file software patched and access-restricted. Attackers do not need to compromise the bank if they can alter a local payroll or AP file generator before the approved data is transmitted.

Review file templates and macros as controlled software. A malicious or accidental formula change can alter amounts or beneficiary fields before export. Lock approved versions and require testing after any payroll or ERP upgrade that changes file generation.

Keep bank confirmation reports in a location independent from the file creator. The approver should be able to compare what the bank accepted with what the source system authorised without relying on a report that could be altered by the same user.

Include third-party payroll or AP providers in the annual control review. A secure internal file can still be altered or misrouted if an outsourced bureau has weak access or change-management procedures.