IBAN Best Practices for Treasury Teams: Controls, Checks, and Workflows

Treasury teams operate at the intersection of the highest payment volumes, the tightest execution windows, and the greatest fraud risk. A payroll team processes dozens of payments per cycle. An accounts payable team processes hundreds per month. Treasury processes interbank transfers, cash pool sweeps, FX settlements, and counterparty payments that can individually represent millions — and the IBAN is the routing mechanism for all of it.

This guide covers the IBAN controls, verification workflows, and governance structures that treasury teams should have in place — not as theoretical best practice, but as operational requirements for any treasury function managing cross-border payment flows.

Why Does Treasury Face Higher IBAN Risk Than Other Finance Functions?

Three factors make treasury the highest-risk function for IBAN-related payment fraud and errors:

Transaction size: Treasury payments are disproportionately large. A single intercompany transfer, loan drawdown, or FX settlement can represent 100 times the value of an average AP payment. The financial consequence of an error — or a fraud incident — scales accordingly.

Counterparty diversity: Treasury maintains relationships with a broader set of counterparties than AP — banks, custodians, broker-dealers, intercompany entities, and external counterparties in multiple jurisdictions, each with their own IBAN structure and banking arrangements.

Time pressure: Treasury payments often have same-day settlement requirements. The pressure to execute before cut-off times creates an environment where shortcuts on verification are tempting and the window for catching errors before funds leave is narrow.

What Should a Treasury IBAN Standing Data Policy Include?

Standing data — the stored bank account details for counterparties, intercompany entities, and beneficiaries — is the most critical control point. Fraud incidents targeting treasury almost universally involve corrupted standing data: a payment instruction that references a legitimately stored counterparty but directs the payment to a fraudulent IBAN.

A treasury IBAN standing data policy should include:

• Dual control for all entries: No IBAN may be added to the standing data file without being entered by one authorized person and confirmed by a second. This applies to new entries and to any modification of existing entries.
• Structural validation at entry: Every IBAN must pass a full structural validation — country code, length, BBAN format, and MOD-97 check digits — before it is stored. Validation must be documented with the date and the name of the validator.
• External confirmation for new counterparties: For any new counterparty, the IBAN and BIC must be confirmed through a formal channel — a signed settlement instruction form, a SWIFT MT999 confirmation, or a secure email from the counterparty's official domain — before the first payment.
• Change blackout period before large payments: Any change to standing data for a counterparty with a pending large payment should trigger an automatic hold on the payment until the change is re-confirmed by a senior treasury officer. The blackout period should be at least 24 hours.
• Quarterly standing data review: All standing data IBANs should be re-validated quarterly using a bulk validation process. Any that fail structural validation or return unexpected bank identifications should be investigated and re-confirmed before the next payment.

How Should Treasury Handle IBANs for Intercompany Transfers?

Intercompany IBANs receive less scrutiny than external counterparty IBANs in most treasury functions — they are owned by entities within the same corporate group and are assumed to be well-controlled. This assumption creates a blind spot.

Intercompany payment fraud, while less common than external BEC attacks, does occur — particularly in organizations where intercompany IBAN management is decentralized, with each subsidiary responsible for maintaining its own bank account register. A fraudulent change to an intercompany entity's IBAN — whether through an insider or an external attacker who has compromised an entity's email system — may not be subject to the same verification controls as a change from an external vendor.

Best practice: apply the same dual-control and structural validation requirements to intercompany IBANs as to external counterparty IBANs. The monetary risk is the same; the internal ownership of the counterparty does not reduce the risk of standing data corruption.

What Pre-Payment Checks Should Treasury Run for Each Transaction?

For each treasury payment, the verification sequence should include:

1. IBAN match to standing data: Confirm that the IBAN in the payment instruction matches the IBAN in the standing data file exactly — character by character. Do not rely on a system match without visual confirmation for high-value payments.
2. Standing data freshness check: Confirm that the standing data for this counterparty has not been modified within the last 48 hours. If it has, apply additional scrutiny: call the counterparty to confirm the payment details before executing.
3. BIC verification: For international transfers, confirm that the BIC accompanying the payment instruction matches the BIC in your standing data and the BIC associated with the IBAN. Use the SWIFT/BIC directory to verify any BIC that appears unfamiliar.
4. Amount plausibility: Confirm that the payment amount is consistent with the counterparty relationship — within the expected range for this counterparty and consistent with underlying documentation (trade confirmation, loan drawdown notice, intercompany settlement schedule).

For organizations with high payment volumes, these checks can be automated using the ibanchecker.cash API integrated into the payment workflow — validating IBANs against standing data at the time of payment instruction creation and flagging discrepancies before they reach the payment execution queue.

How Should Treasury Respond to a Suspected IBAN Fraud Incident?

The response sequence for a suspected treasury IBAN fraud incident:

1. Immediate recall request: Contact your bank's treasury services desk immediately — within the first hour if possible. SWIFT payment recalls initiated within the same business day have a significantly higher recovery rate than those initiated later. Provide the payment reference, amount, execution date, and destination IBAN.
2. Freeze the standing data record: Lock the affected counterparty's standing data record to prevent further payments while the incident is under investigation.
3. Counterparty notification: Contact the legitimate counterparty through a verified channel to confirm whether the payment was expected and whether their bank details were changed legitimately.
4. Internal escalation: Notify the CFO, head of treasury, and information security team. Preserve all email and system logs related to the standing data change and the payment instruction.
5. Law enforcement report: File a report with the relevant financial crime authority (Action Fraud in the UK, FBI IC3 in the US, BKA in Germany). Some banks and insurance policies require a police reference number before processing a fraud claim.

How Do You Build IBAN Validation Into Treasury Workflows Without Creating Bottlenecks?

The objection most treasury teams raise to rigorous IBAN verification is operational: the payment cut-off is in 30 minutes, the counterparty is waiting, and a 10-step verification process is incompatible with the pace of treasury operations.

The answer is to separate standing data management from payment execution. The verification controls belong at standing data entry — when a counterparty IBAN is first stored or modified — not at payment execution. If your standing data is well-controlled and regularly audited, the payment execution step needs only to confirm a match to standing data, which is a 10-second check.

The bulk IBAN checker handles standing data audits efficiently — export your counterparty list, upload it, and get a validated result in under a minute. The ibanchecker.cash API integrates into treasury management systems (Kyriba, Reval, SAP TRM, FIS Quantum) to automate validation at the standing data entry point, eliminating the manual check entirely without compromising the control.

Treasury teams that invest in standing data controls consistently report fewer payment errors, faster payment execution, and lower remediation costs than those that treat IBAN verification as a payment-execution task. The verification work happens once, at standing data entry. The payment executes with confidence.

Last updated: June 2026