How does APP fraud exploit IBAN payments specifically?

The IBAN system verifies the structural integrity of an account number (MOD-97 check digits, country code, correct length) but does not, in most payment types, confirm that the account name matches the IBAN. An attacker who substitutes a legitimate IBAN with one they control will have a structurally valid IBAN that passes all format checks. The payment infrastructure executes the transfer to the fraudulent account without raising a flag. The fraud is relational — the wrong IBAN is being paid — not structural.

Can IBAN validation stop APP fraud?

IBAN format validation alone cannot stop APP fraud because fraudulent IBANs are structurally valid. However, bank-name validation — comparing the institution returned by an IBAN lookup against your supplier record — can detect IBAN substitution when the attacker routes funds through a different bank than the one on file. Validate every beneficiary IBAN at onboarding, store the bank name alongside the IBAN, and re-validate before each payment run. Any change in bank name is a signal that the IBAN may have been substituted.

What is the EU doing to prevent APP fraud?

The EU's Instant Payments Regulation (2024/886) requires payment service providers to offer Verification of Payee (VoP) for euro instant credit transfers, with enforcement from January 2025. VoP asks the beneficiary bank to confirm whether the account name matches the IBAN, returning a match, close match, or no-match result. A no-match should halt the payment pending review. The forthcoming PSD3 is expected to extend VoP requirements to standard SEPA Credit Transfers.

Authorized Push Payment Fraud: How Criminals Exploit IBAN Transfers

Q: What is authorized push payment fraud?

Authorized push payment (APP) fraud is a type of scam where criminals trick the victim into voluntarily sending money to an IBAN they control. Unlike card fraud, the victim authorizes the payment themselves — typically after being deceived into believing they are paying a legitimate supplier, bank, or institution. Because the payment is authorized by the victim, banks have historically been reluctant to refund losses, though UK and EU regulations are introducing mandatory reimbursement obligations.

Authorized push payment (APP) fraud is the fastest-growing category of payment crime in Europe and the UK. Unlike traditional card fraud, where a criminal uses stolen credentials to make an unauthorized transaction, APP fraud tricks the victim into authorizing the payment themselves — to an IBAN controlled by the attacker. Because the victim initiated the transfer, banks have historically been reluctant to refund the loss, and recovery from the beneficiary bank is rarely successful. This guide explains how APP fraud exploits IBAN-based payment systems, what the attack patterns look like, and what individuals and finance teams can do to protect themselves.

What Is Authorized Push Payment Fraud?

In an APP fraud attack, the victim is manipulated into sending money to a fraudulent IBAN by believing they are paying a legitimate party. The payment instruction is authorised by the victim — it is not a hack of the banking system. The fraud lies in the deception that precedes the authorization: the victim is convinced that the IBAN belongs to their bank, their landlord, their supplier, or a trusted institution.

APP fraud operates through several distinct scenarios. In purchase scams, the victim pays for goods or services that never arrive. In investment scams, the victim transfers funds to what appears to be a trading account. In impersonation scams, the attacker poses as a bank, government agency, or utility company and instructs the victim to move funds "for security." In invoice fraud, the attacker intercepts a legitimate payment instruction and replaces the IBAN. In all cases, the fraudulent IBAN is structurally valid and passes every technical check the bank performs before processing.

Why Do IBANs Make APP Fraud So Effective?

The IBAN system was designed for interoperability and automated processing, not for verifying the relationship between an account number and its holder. When a payer submits an IBAN for a SEPA Credit Transfer or SWIFT payment, the sending bank checks that the IBAN is structurally valid — correct country code, correct length, MOD-97 check digits pass. It does not, in most cases, confirm that the account name matches the IBAN.

This verification gap is what APP fraud exploits. The attacker's IBAN is real. It belongs to a real account at a real bank. The MOD-97 algorithm produces a valid result. Nothing in the structural validation catches the fraud, because the fraud is not structural — it is relational. The wrong IBAN is being paid.

The EU's Instant Payments Regulation (2024/886) introduced a mandatory IBAN-name matching requirement for euro instant credit transfers, which began phased enforcement in January 2025. But this applies only to instant transfers within the EU and only where both banks support the Verification of Payee (VoP) protocol. Standard SEPA Credit Transfers, SWIFT payments, and transfers involving non-EU banks carry no equivalent requirement.

What Are the Most Common APP Fraud Attack Patterns?

Understanding the mechanics of each attack pattern helps finance teams and individuals recognize the warning signs before a payment is made.

Supplier impersonation (invoice fraud): The attacker compromises or spoofs a supplier's email account and sends a payment instruction containing a fraudulent IBAN. Often the instruction arrives as a PDF invoice with the bank details changed. The payer recognizes the supplier's branding and processes the invoice without verifying the IBAN against a trusted record. UK Finance reported that supplier impersonation accounted for £95 million in APP fraud losses in 2023.

Safe account scams: The attacker impersonates the victim's bank and claims that their account has been compromised. The victim is instructed to move funds immediately to a "safe account" — an IBAN controlled by the attacker. The urgency and apparent authority of the instruction cause the victim to act without questioning the IBAN's legitimacy.

Romance and investment fraud: Over weeks or months, the attacker builds a relationship with the victim online and eventually asks them to send money via IBAN transfer — for an emergency, an investment opportunity, or a shared goal. By the time the transfer is made, the victim fully trusts the beneficiary.

Real estate payment diversion: An attacker monitors email exchanges between a buyer and a solicitor, then sends a fraudulent bank detail notification timed to coincide with a legitimate payment request. Property transactions are high-value and time-pressured, making them prime targets. The IBAN in the fraudulent instruction looks similar to the real one — same country code, same bank code prefix in some cases.

How Can Organizations Reduce APP Fraud Risk?

No single control eliminates APP fraud risk, but a layered approach that combines technical validation with process controls significantly reduces exposure.

Validate every new IBAN at onboarding. Before adding a supplier, payee, or beneficiary to your payment system, validate their IBAN using the ibanchecker.cash IBAN checker or the ibanchecker.cash API. The validation returns the bank name and BIC, which should be recorded alongside the IBAN. Any future payment instruction referencing that IBAN can then be compared against the stored bank record.

Confirm IBAN changes out of band. Any request to update a beneficiary's IBAN — whether received by email, post, or phone — must be confirmed via a separate channel before the change takes effect. Call the beneficiary on their registered number (not one provided in the change request). Never accept IBAN changes by email alone.

Apply dual authorization for high-value payments. Require a second approver for payments above a defined threshold. The second approver should independently verify the beneficiary IBAN against your supplier record — not simply co-sign the same payment screen.

Run periodic bulk re-validation. Use the bulk IBAN checker to re-validate your entire supplier IBAN database quarterly. If any IBAN now resolves to a different bank than when originally added, flag it for review before the next payment run.

Train accounts payable staff. Accounts payable teams are the primary target. Staff should know how to identify urgency language, lookalike email domains, and requests to bypass normal verification. Conduct periodic simulated APP fraud exercises to test awareness.

What Happens After an APP Fraud Payment Is Made?

Recovery after an APP fraud payment is difficult. In the UK, the Payment Systems Regulator (PSR) introduced mandatory reimbursement for Faster Payments APP fraud from October 2023 — banks and payment firms must reimburse victims up to £415,000 unless the victim acted with gross negligence or ignored explicit fraud warnings. Within the EU, reimbursement obligations vary by member state and depend on whether the victim can demonstrate that they took reasonable care.

For corporate victims, recovery through banking channels is rarely straightforward. The SWIFT gpi payment recall mechanism allows sending banks to initiate a recall request, but the beneficiary bank is not obligated to comply, and funds withdrawn by the attacker before the recall is processed are practically unrecoverable. The most effective approach is prevention — stopping the payment from being made to the wrong IBAN in the first place.

How Does IBAN Validation Fit Into a Broader APP Fraud Defense?

IBAN validation is a necessary but not sufficient control. A fraudulent IBAN is structurally valid — it will pass the MOD-97 check. What validation provides is the ability to compare the bank associated with an IBAN against a previously verified record. If the bank name or BIC returned by validation does not match what is on file for that supplier, the discrepancy is a strong signal that the IBAN has been substituted.

Integrate validation at three points: onboarding (when the IBAN is first received), change events (when a beneficiary submits a new IBAN), and periodic audit (quarterly re-validation of your full payee database). The ibanchecker.cash REST API can be embedded directly into your ERP or accounts payable workflow to automate this validation without storing any IBAN data — all processing is in-memory and compliant with GDPR.

Last updated: June 2026