Treasury and Corporate Payment System Security Guide

A corporate payment can be stolen without touching the bank at all: change a supplier's bank details, edit a payment file after approval, or reuse a signer's credentials, and the bank will faithfully pay the attacker. Treasury management systems (TMS), ERP payment runs, bank portals and the file or API links between them form a chain where every hand-off is a place to alter the payee, the amount or the approval. This guide covers how to secure that chain end to end: the TMS and ERP payment modules, bank connectivity (host-to-host SFTP, EBICS, Swift, bank APIs and portals), payment file integrity, approval and signing controls, and payee verification schemes. It is written for treasury operations, finance systems owners and the security architects who support them. Email fraud awareness is covered elsewhere; this page is about the systems and controls that stop a fooled human, or a compromised account, from moving money.

Key takeaways

Protect the payment, not just the systems. Most losses come from legitimate systems used to send correctly formatted payments to the wrong account, so controls must check payee, amount and approval at each hand-off.
The file between approval and the bank is the weakest link. A payment file sitting unsigned in a shared folder or SFTP outbox can be edited after approval; sign or hash it at the point of approval and verify before transmission.
Bank detail changes are the highest-risk transaction. Treat any new or changed beneficiary account as a payment in its own right: separate requester and approver, call-back to a known number, and a cooling-off period.
Bank connectivity credentials are non-human identities. SFTP keys, EBICS keys, API client certificates and portal tokens move money and need owners, rotation, vaulting and monitoring like any privileged credential.
Use the payee checks the payment schemes now give you. UK Confirmation of Payee, EU Verification of Payee under Regulation (EU) 2024/886 and US Nacha fraud monitoring rules change what banks check; do not opt out of bulk checks without a compensating control.

The corporate payment chain and where it is attacked

A typical corporate payment passes through five stages. Each one has a different owner and a different attack.

Stage	Typical systems	How it is attacked	ATT&CK reference
1. Payee master data	ERP vendor master, TMS beneficiary list, payroll	Fraudulent change of supplier bank details after a phishing or impersonation request; insider adds a beneficiary	T1566 Phishing, T1534 Internal Spearphishing
2. Payment proposal and approval	ERP payment run, TMS workflow, bank portal	Compromised approver account, approval rules bypassed, self-approval	T1078 Valid Accounts
3. Payment file generation and storage	ERP export, TMS output folder, middleware, managed file transfer	File edited after approval (account number or amount swapped), file injected into outbox	T1565.001 Stored Data Manipulation
4. Transmission to the bank	Host-to-host SFTP, EBICS, Swift, bank API, portal upload	Stolen transport credentials or keys, file altered in transit through a compromised intermediary	T1565.002 Transmitted Data Manipulation
5. Bank execution and reporting	Bank statements (camt.053, MT940), reconciliation	Mailbox rules hide bank alerts, statements not reconciled quickly enough to recall funds	T1114.003 Email Forwarding Rule, T1657 Financial Theft

The scale of stage 1 and 2 fraud is well documented. The FBI's Internet Crime Complaint Center reported exposed losses of more than $55 billion in business email compromise incidents worldwide between October 2013 and December 2023, and its prevention advice starts with using secondary channels to verify requests to change account information. See the Business Email Compromise and Fraud Statistics Guide for current figures.

Securing the TMS and ERP payment modules

The TMS (or the ERP's payment and bank communication modules) is where payees are held, payments proposed and approvals recorded. Harden it as a financial control system, not a general business application.

Authentication: single sign-on with phishing-resistant MFA for every user who can create, change or approve payments or beneficiaries. Remove local accounts except one break-glass account held in a vault. See the Phishing-Resistant MFA Guide.
Roles and segregation of duties: separate the roles that maintain beneficiaries, create payments, approve payments, administer workflow rules and administer users. A system administrator who can also approve payments, or change approval limits, defeats every other control. Map conflicts in a Segregation of Duties Matrix Template.
Approval rules: dual approval for every payment, with a second senior approver above thresholds you set by currency and payee type. Approval rules should be enforced by the system, not by procedure, and changes to rules should themselves need dual approval.
Beneficiary controls: new or changed beneficiaries cannot be paid until a second person has approved the change and a call-back has been recorded. Many organisations add a cooling-off period (for example 24 to 72 hours, an NHI Mgmt Group recommendation) before the first payment to a new account.
Configuration change control: payment formats, bank connectivity settings and file paths are high-risk configuration. Changes go through change management with test evidence and are logged.
Hosting: SaaS TMS shifts patching to the provider but keeps identity, roles and integrations with you. On-premises TMS needs the server, database and file shares hardened as a tier-zero financial system.

Where the ERP drives payments, review the ERP side too: vendor master change workflows, payment run authorisations and the technical users that export files. See the ERP platform integration security guide and the SAP and ERP Security Buyer's Guide.

Bank connectivity options and their security trade-offs

How you connect to banks determines which credentials exist, where files are exposed and what the bank can verify.

Channel	How it works	Security strengths	What to watch
Bank web portal	Users key or upload payments in each bank's portal	Bank-side MFA and approval workflows; no file sitting on your network	Many separate logins per bank, inconsistent approval rules, uploads from desktops, leaver accounts left active
Host-to-host SFTP	ERP or TMS drops files on an SFTP server; files often PGP-encrypted and signed	Automated, no manual handling; payload signing possible	SSH and PGP keys on servers, files waiting in outbox folders, signing often skipped
EBICS	Standard bank-customer protocol used mainly in Germany, France, Switzerland and Austria	Transport and application-level encryption; Electronic Distributed Signature lets several signers authorise one order	Key initialisation letters and signer keys must be protected; signature keys stored on servers weaken user-level authorisation
Swift (corporate access or service bureau)	Corporate sends payments over the Swift network, directly or via a bureau	One channel to many banks; Swift Customer Security Programme controls apply to the local footprint	Annual CSCF attestation, operator accounts and the Swift interface host become high-value targets
Bank APIs	TMS calls bank REST APIs for payments, status and balances	Real-time status, fine-grained scopes, mutual TLS and signed requests where the bank supports them	Client certificates and OAuth tokens become payment credentials; each bank's API security model differs

The EBICS standard is maintained by the EBICS company; specification version 3.0.2 has been valid since 30 December 2022, and its security annex was renamed "TLS and KMS" in March 2026 to add key management security. In EBICS, orders are signed with the subscriber's bank-technical signature key, and the distributed signature lets a second signer approve an order later from elsewhere. Keep signature keys with the people who authorise, not in a shared technical account, or you lose the four-eyes principle the protocol was designed to give you. For Swift users, see the SWIFT Customer Security Programme (CSP) Guide.

Payment file integrity from approval to bank

Most organisations approve a payment in one system and transmit a file from another. The integrity gap between those points is where an attacker with file share access can change an IBAN without touching any approval record.

Generate as late as possible: create the payment file (for example an ISO 20022 pain.001 credit transfer initiation) from the approved batch, immediately before transmission, by a system process rather than a person.
Bind the file to the approval: record a hash of the file contents (or a control total of amounts and a hash of beneficiary accounts) at approval time, and verify it again in the transmission step. Any mismatch stops the run.
Sign the payload: use payload signing the bank supports (PGP signing on SFTP, EBICS order signatures, signed API requests) so the bank can detect alteration in transit. Keep signing keys in an HSM or key vault, not on the file server. See the Payment HSMs guide.
Remove manual touch points: no editable files on user drives, no "download, check, upload" steps in portals. If manual upload cannot be avoided, the uploader should not be able to edit the file and the portal should require approval by a second user.
Lock down outbox folders: only the generating service writes, only the transfer service reads, and nobody browses interactively. Monitor the folders with file integrity monitoring and alert on any write by another account. See the File Integrity Monitoring Guide.
Reconcile fast: pull bank status and statement messages (for example pain.002 status reports and camt.053 statements) automatically and compare executed payments with approved batches the same day.

A managed file transfer platform can centralise these steps, but only if it is itself protected. See the Managed File Transfer Buyer's Guide.

Where identity fits: bank credentials are machine identities

Every automated bank link runs on non-human credentials: SSH keys for SFTP, PGP keys for signing and encryption, EBICS authentication, encryption and signature keys, client certificates for mutual TLS, and OAuth client secrets for bank APIs. Each one can move money or read cash positions. Treat them as privileged credentials:

Inventory: list every bank connection with its credential type, location, owner, expiry and the bank contact who can revoke it.
Storage: keys in an HSM or secrets vault, never in scripts, job definitions or configuration files. See the SSH Key Management Guide and API Key Management Guide.
Rotation and revocation: agreed procedures with each bank, tested before you need them in an incident. Know how long a bank takes to deactivate a key.
Human signers: payment signatory rights at the bank must match the current approval matrix. Leavers must be removed from bank mandates and portals, not only from the TMS.

Access to the wider payment estate (TMS admin, ERP technical users, file servers) should go through privileged access management. See the Privileged Access Management Guide.

Payee verification and scheme rules

Payment schemes have added payee checks that corporates should build into their process rather than bypass.

Scheme or rule	What it does	Status (checked November 2026)	What corporates should do
Verification of Payee, Regulation (EU) 2024/886, Article 5c	The payer's PSP must check payee name (or a registration identifier such as LEI for legal persons) against the account before the payer authorises a credit transfer	Applies to euro area PSPs from 9 October 2025 and to non-euro Member States from 9 July 2027	PSPs must let non-consumers opt out for bulk packages; only opt out if you run your own equivalent check, and handle "no match" and "close match" results in your workflow
Confirmation of Payee (UK, Pay.UK)	API-based account name check before a payment, including a personal or business account indicator	Operating overlay service	Use it when setting up new beneficiaries and for changed bank details; Payer Name Verification covers Bacs Direct Debit set-up
Nacha fraud monitoring rules (US ACH)	Non-consumer originators, third-party senders and ODFIs must have risk-based processes to identify entries that are unauthorised or authorised under false pretenses, reviewed at least annually	Phase 1 from 20 March 2026 (larger originators and all ODFIs), Phase 2 from 19 June 2026, with a practical effective date of 22 June 2026 because 19 June is a US federal holiday, per Nacha (all others)	Document your monitoring of outgoing ACH credits, including beneficiary change controls, and review it yearly

A payee check does not replace a call-back. Attackers open accounts in names that pass the check, and some payments fall outside the schemes. See the Payment Verification Policy Template.

Implementation approach

Map the chain: for each bank and payment type, record the systems, files, credentials, people and approvals involved. This is usually the first time anyone has seen it whole.
Fix beneficiary controls first: dual control and call-back on bank detail changes give the largest reduction in loss for the least effort. Pilot with accounts payable, then payroll and treasury.
Enforce MFA and SoD in the TMS and portals: remove shared logins, apply role separation, and review who can approve at each bank.
Close the file gap: introduce hashing or control totals between approval and transmission. Run it in alert-only mode for a month to find legitimate mismatches (format conversions, re-generations), then switch to blocking.
Vault and rotate bank credentials: move keys off servers, agree rotation with each bank, and test revocation.
Add monitoring: stream TMS, ERP, SFTP and portal logs to your SIEM with the use cases below.
Rehearse: run a tabletop for a fraudulent payment, covering recall requests, bank contacts and evidence. See the Business Email Compromise Response Playbook.

Rollback: every new blocking control should have a documented manual fallback (for example, a dual-signed portal payment) so that urgent payments are not forced through uncontrolled channels when a control fails.

Detection and measurement

Monitor for these events:

Beneficiary or vendor bank detail created or changed, especially followed by a payment within days.
Approval rule, limit or role changes in the TMS or bank portal.
Logins to TMS or bank portals from new devices, countries or at unusual times, and MFA resets for payment users.
Writes to payment outbox folders by any account other than the generating service; hash mismatches at transmission.
Use of bank transmission credentials from unexpected hosts, and new SSH or PGP keys added.
Mailbox rules in finance mailboxes that move or delete bank notifications.

Metrics that show the programme works:

Metric	Target direction
Percentage of beneficiary changes with recorded call-back and second approver	100%
Payment users and bank signers with phishing-resistant MFA	100%
Bank connections with keys in an HSM or vault and a named owner	Rising to 100%
Payment batches verified by hash or control total before transmission	100%
Time from payment execution to reconciliation	Same day
Leavers removed from bank mandates within agreed days	Within policy

Framework mapping

Control area	NIST SP 800-53 Rev. 5	NIST CSF 2.0	ISO/IEC 27001:2022 Annex A
Segregation of duties in payment roles	AC-5, AC-6	PR.AA-05	5.3 Segregation of duties
Strong authentication for payment users	IA-2	PR.AA-01	8.5 Secure authentication
Payment file integrity	SI-7, SC-8	PR.DS-01, PR.DS-02	8.24 Use of cryptography
Bank connection keys	SC-12, SC-13	PR.AA-01	8.24 Use of cryptography
Change control of formats and workflows	CM-3	PR.PS-01	8.32 Change management
Monitoring and log review	AU-2, AU-6	DE.CM-09	8.15 Logging, 8.16 Monitoring activities

Common failure patterns

Bank detail changes accepted by email: a supplier "update" is processed by one clerk and paid in the next run. Call-back to a number from the master record, not the request, is the fix. See Business Email Compromise Awareness for Finance Teams Guide.
Approval in one system, file in another: payments are approved in the ERP but the file sits editable on a share for hours before an SFTP job picks it up.
Technical signer keys: EBICS or portal signing keys held by a service account so that "dual approval" is performed by one process.
Forgotten bank access: former employees remain on bank mandates or portal user lists because the bank side is not part of the leaver process.
Bulk opt-out without a substitute: verification of payee is switched off for bulk files to avoid friction, with no internal check in its place.
Cloud credentials used for payment fraud: stolen keys can be used to send convincing mail from your own domains, as in TruffleNet 2025, so finance teams cannot rely on sender domain alone.

Practitioner checklist

Map every payment path from payee master data to bank execution, with systems, files, credentials and approvers.
Enforce dual control, call-back and a cooling-off period on new and changed beneficiaries.
Require phishing-resistant MFA for everyone who can change payees or approve payments, in the TMS, ERP and bank portals.
Separate payee maintenance, payment creation, approval and system administration roles, and review conflicts quarterly.
Hash or control-total payment files at approval and verify before transmission.
Sign payment payloads and keep signing and transport keys in an HSM or vault with named owners.
Agree key rotation and emergency revocation procedures with every bank, and test them.
Use Verification of Payee or Confirmation of Payee results in your workflow and avoid bulk opt-outs without an equivalent control.
Reconcile bank statements against approved batches the same day and alert on differences.
Remove leavers from bank mandates and portals as part of the standard leaver process.

Treasury and Corporate Payment System Security Guide: Protecting TMS, Bank Links and Payment Files