What is the most effective technical control against BEC payment fraud?

The combination of email authentication (SPF, DKIM, DMARC with p=reject policy) and IBAN bank-name validation is the most effective technical layer. DMARC prevents your domain from being spoofed in outbound fraud and gives you visibility into spoofing attempts. IBAN bank-name validation — comparing the institution returned by a lookup against your supplier record — catches IBAN substitution at the point of payment processing, before the transfer is authorized. Neither control alone is sufficient: DMARC does not protect against account takeover, and IBAN validation does not detect domain spoofing.

What should we do immediately if we suspect a payment went to a fraudulent IBAN?

Act within hours. Contact your bank's fraud team immediately and request a recall of the payment — under SWIFT gpi, recall requests can be initiated and tracked in real time, and speed significantly increases the probability of recovery before the attacker withdraws funds. File a report with your national cybercrime unit (Action Fraud in the UK, FBI IC3 in the US, EC3 at Europol for EU cases). Notify your cyber insurance provider. Preserve all email evidence — headers, attachments, the original and modified payment instructions — and do not delete anything before your fraud team and legal counsel have reviewed it.

Business Email Compromise and IBAN Fraud: Detection and Prevention

Q: How does business email compromise target IBAN payments?

In a BEC attack targeting IBAN payments, the attacker either compromises a real email account (via phishing or credential theft) or impersonates a legitimate sender using a lookalike domain. They intercept or fabricate a payment instruction containing a legitimate IBAN and replace it with an IBAN they control. The victim authorizes the payment believing they are paying the correct beneficiary. Because the fraudulent IBAN is structurally valid, it passes all format checks and the payment is processed normally. The fraud is detected only when the legitimate supplier reports non-receipt.

Business Email Compromise (BEC) is the most financially damaging form of cybercrime according to the FBI's Internet Crime Complaint Center, with losses exceeding $2.9 billion in the United States alone in 2023. The majority of BEC attacks in SEPA and SWIFT payment environments result in fraudulent IBAN transfers — the attacker manipulates the victim's payment instruction so that funds are wired to an IBAN they control. This guide explains how BEC attacks target IBAN-based payment workflows, the technical and organizational controls that detect them, and how finance teams can build a prevention program that doesn't create unacceptable friction for legitimate payments.

How Does Business Email Compromise Target IBAN Payments?

BEC is not a single attack technique — it is a category of fraud that uses compromised or impersonated email to manipulate payment decisions. In IBAN payment contexts, the attacker's goal is always the same: to replace a legitimate beneficiary's IBAN with one under their control in a payment instruction that the victim then authorizes.

The attack can originate from three different starting points. In account takeover BEC, the attacker has compromised a real email account — either the supplier's or the buyer's — using credentials obtained through phishing, credential stuffing, or purchase on dark web markets. They monitor the inbox for payment-related correspondence, then intervene at the moment a payment instruction is being exchanged.

In domain impersonation BEC, the attacker registers a domain that looks like the legitimate supplier's — for example, acme-invoices.com in place of acme.com — and sends a payment instruction from that domain. The email display name shows the legitimate contact's name; only inspecting the actual sending address reveals the fraud.

In executive impersonation (CEO fraud), the attacker poses as a senior executive within the victim organization and instructs a finance team member to make an urgent, confidential payment to a new IBAN. The authority of the apparent sender and the confidentiality instruction together suppress the victim's normal verification instinct.

What Makes IBAN Transfers Particularly Vulnerable to BEC?

IBAN-based payments are processed based on the account number. In most SEPA and SWIFT payment types, the beneficiary name in the payment instruction is not verified against the IBAN — the payment goes wherever the IBAN directs, regardless of the name field. This means that once an attacker substitutes the IBAN, the payment infrastructure will execute the transfer without raising a flag, even if the beneficiary name in the instruction is entirely fictitious.

The EU's Verification of Payee (VoP) regulation (effective January 2025 for instant transfers) introduces mandatory name-IBAN matching for euro instant credit transfers, but this applies only to instant payments and only where both banks support the VoP protocol. Standard SEPA Credit Transfers and SWIFT payments remain without a mandatory name-match check in most cases.

Additionally, IBAN transfers above the SEPA minimum threshold are generally final — once the payment has settled, recovery requires the voluntary cooperation of the beneficiary bank, which is not guaranteed. BEC attacks targeting IBAN payments are therefore designed for speed: the attacker withdraws funds from the receiving account before a recall request can be processed.

What Are the Technical Controls for Detecting BEC in Payment Workflows?

Technical controls cannot replace human judgment, but they can catch the majority of BEC attempts before a fraudulent payment instruction reaches an authorizer.

Email authentication (SPF, DKIM, DMARC). Configure Sender Policy Framework, DomainKeys Identified Mail, and Domain-based Message Authentication, Reporting and Conformance for your domain. A DMARC policy of p=reject prevents spoofed emails using your domain from reaching recipients, and DMARC reporting gives you visibility into spoofing attempts. Require your key suppliers to have equivalent protections in place.

IBAN validation at the point of receipt. When a payment instruction arrives containing an IBAN, validate it immediately using the ibanchecker.cash API and compare the returned bank name against your supplier record. If the bank name has changed since the last payment, the instruction should be held for manual review before it enters the payment queue. For automated processing, this can be embedded in your accounts payable intake workflow.

IBAN change detection in ERP. Configure your ERP or payment system to flag any change to a stored beneficiary IBAN as a high-risk event requiring separate approval. The change should not become active until it has been confirmed through an out-of-band verification process (phone call to a registered number) and approved by someone with appropriate authority.

Payment anomaly monitoring. Monitor for payment instruction patterns that deviate from baseline: amounts significantly larger than the typical transaction size with a supplier, a first payment to a new IBAN following a bank detail change request, or payments initiated outside normal business hours. These patterns do not confirm fraud, but they justify a verification hold before processing.

What Organizational Controls Prevent BEC Payment Fraud?

Organizational controls address the human element of BEC — the social engineering that technical controls cannot fully prevent.

Dual authorization for high-value payments. Payments above a defined threshold must be approved by two separate individuals. The second approver independently verifies the beneficiary IBAN against the supplier record — they do not simply confirm what the first approver has already reviewed.

Callback verification policy. Any new IBAN, or any change to an existing IBAN, requires a callback to the beneficiary using a phone number from your existing verified records — never a number provided in the same communication as the IBAN change request. Document the callback: date, time, person spoken to, confirmation received.

No exceptions for urgency or authority. A stated policy that urgent payment requests and requests from senior executives follow the same verification process as any other payment removes the social engineering lever that CEO fraud relies on. Staff should be empowered to delay a payment for verification without fear of reprimand, even if the apparent requester expresses frustration.

Supplier bank detail portal. Route all bank detail submissions and changes through a secured supplier portal with multi-factor authentication, rather than accepting them by email. The portal creates a documented record of who submitted what, when, and from which authenticated session.

Staff awareness training. BEC attacks exploit social norms — authority, urgency, familiarity. Regular training that explains these mechanisms and gives staff examples of real BEC patterns (with simulated exercises) significantly reduces the probability that a fraudulent instruction will be processed without verification.

What Should You Do If You Suspect a BEC Payment Instruction?

If a payment instruction exhibits BEC characteristics — an unsolicited IBAN change, an urgent tone, a sender domain that looks slightly different, or a bank name that does not match your records — the response should follow a consistent protocol:

Do not process the payment. Place a hold on the instruction.
Validate the IBAN at the ibanchecker.cash checker and record the bank name and BIC returned. If the bank differs from your supplier record, treat the instruction as fraudulent until confirmed otherwise.
Contact the supplier using a phone number from your verified records — not from the suspicious email. Confirm whether they sent the payment instruction and whether the IBAN is correct.
If the instruction is confirmed as fraudulent, report it to your local cybercrime unit (Action Fraud in the UK, the FBI IC3 in the US, EC3 at Europol for EU cases), and notify your bank's fraud team immediately. Speed matters — if funds have already been transferred, a rapid recall request may recover them before withdrawal.
Document the incident, including the evidence gathered, who was involved, and what actions were taken. This record supports any regulatory reporting obligation and insurance claim.

How Can IBAN Validation Be Integrated into a BEC Prevention Program?

The ibanchecker.cash API provides a programmatic validation endpoint that can be embedded at every point in your payment workflow where an IBAN is received or updated. A POST to /api/v1/validate returns the bank name, BIC, country, and validity result in under 100 ms. The result can be compared automatically against your stored supplier bank record, with any mismatch triggering a workflow hold and alert.

For bulk pre-payment validation — running your full payment file before each payment run — the bulk IBAN checker or the /api/v1/validate/bulk endpoint accepts up to 100 IBANs per request. Any IBAN that resolves to a different bank than the one on record is excluded from the payment run and routed to manual review.

All validation is performed in memory — no IBAN data is retained, which supports GDPR compliance and data minimisation requirements. The bank name returned by validation is what you store, not the IBAN itself, reducing your exposure in the event of a data breach.

Last updated: June 2026