Invoice fraud and the IBAN swap: how to prove which email is the original
Invoice fraud is almost never decided on the day the payment leaves. It gets decided six weeks later, when the supplier chases an invoice that accounts payable has already closed as paid, and the two companies work out that they are holding two different PDFs carrying the same invoice number. In most finance functions the same document travels twice: once through the accounting and archiving chain, once as a courtesy attachment on an ordinary email. The bank details are read off the second copy. Nobody keeps the second copy in a form that can be verified later.
The numbers say who ends up carrying the loss. Fraudulent credit transfers in the EU and the wider European Economic Area reached EUR 2.5 billion in 2024, and roughly 85% of those losses stayed with the payment service user, which in a business-to-business case means the paying company (EBA and ECB, 2025 Report on Payment Fraud). The bank, in the large majority of cases, does not absorb it.
Once the money is gone the conversation stops being about security and turns documentary. Compliant archiving proves that the invoice deposited in the archive has not been altered since deposit. It says nothing about which file arrived attached to an email, or which IBAN that file contained when the treasurer opened it. Business email compromise lives exactly in the gap that archiving does not cover, and a company that cannot show which version of the email and of the attachment is the original risks paying twice: once to the fraudster, once to the supplier.
How the IBAN swap works on a genuine invoice
The IBAN swap is a form of invoice fraud that does not forge the document, it intercepts it. Europol describes this variant as fraudsters "exploiting genuine invoices where the legitimate suppliers' bank details have been altered", after they have illicitly gained access to a company's email communication and studied its internal structures and operating procedures (Europol, Online Fraud Schemes). The sequence has three steps. The attacker gets inside one of the two mailboxes, usually the smaller supplier's, and stays quiet for weeks. They watch for messages containing the words payment and invoice, and wait for a real document to be sent. At that point they change one string, the IBAN in the attachment, leaving the invoice number, the amount and the letterhead untouched, and forward the message on. What lands in the customer's mailbox is an invoice that is correct in everything except the account the transfer will be made to.
UK and Irish practitioners call the same thing payment diversion fraud or bank mandate fraud; continental European consumer press has settled on IBAN swap. The label matters less than the family it belongs to. This is a BEC attack, the compromise of business email accounts to obtain the information needed to complete the scheme. In 2025 the FBI's Internet Crime Complaint Center logged 24,768 business email compromise complaints and USD 3.05 billion in losses, an average of roughly USD 123,000 per report, second only to investment fraud among all reported crime types by total loss.
Intercepting the thread between supplier and customer
Access to the conversation happens in three ways. The first is direct compromise of the mailbox, with credentials harvested through phishing. The second is a lookalike domain, registered with a single character of difference, so the exchange is quietly moved onto a thread that looks like the continuation of the real one. The third, and the hardest to spot, is thread insertion: the attacker, already inside one of the two mailboxes, replies to a genuine message with the history quoted underneath, the right signature block and the right purchase order references. Nothing in the content is odd. Only the IBAN is different.
Social engineering is where this starts, not the network perimeter. ENISA puts phishing at roughly 60% of the incidents it analysed between July 2024 and June 2025, and reports that by early 2025 AI-supported phishing campaigns accounted for more than 80% of observed social engineering activity worldwide (ENISA Threat Landscape 2025). The old advice about watching for broken grammar has stopped working.
The attachment itself is not rebuilt, it is retouched. The account details are replaced in place, keeping the same font and position, or covered with a white box carrying the new IBAN. The covering note stays plausible: a change of bank, a new group treasury account, the usual account frozen for a few days. On an unsigned PDF, which is what almost every courtesy invoice is, nothing inside the file says which of the two versions the supplier actually issued.
Why the anomaly only surfaces at the payment reminder
The payment goes out normally. It is authorised, it carries the second signature, and in the ledger the invoice shows as settled. The supplier receives nothing but, on 60 or 90 day terms and without daily reconciliation, does not notice for weeks. The reminder arrives after the due date, the customer answers that it paid weeks ago, the supplier answers that nothing ever arrived. Only then does anyone put the two attachments side by side.
By that point the recovery window that matters has closed. A SEPA recall can only be initiated by the originator's bank, and where the reason is a fraudulent origin the SEPA Credit Transfer Rulebook allows up to 13 months from the execution date, with the beneficiary bank required to answer within 15 banking business days (European Payments Council, 2025 SCT Rulebook). Generous on paper. In practice a recall only works while the funds are still sitting in the beneficiary's account, and they are usually split across several accounts within hours. The FBI reports a 58% success rate on freezing funds through its Financial Fraud Kill Chain in 2025, on cases escalated immediately (FBI, 2025 Internet Crime Report). After six weeks what is left is the dispute with the supplier.
Why this is decided on proof, not on security
When the shortfall surfaces, the outcome turns on a documentary question: which version of the invoice reached the company, and when. Neither side can usually answer it in a way anyone else can check. Technical defences have little bearing at that stage, because the compromised mailbox may well have been the supplier's, the payment was authorised properly, and the bank executed the unique identifier it was given. Payer manipulation, the category the IBAN swap belongs to, rose from 65% to 74% of the value of fraudulent credit transfers in Europe between 2023 and 2024 according to the joint EBA and ECB report. These are transactions the customer authorised, not intrusions into banking systems. The company's defence therefore moves onto ground nobody prepared: showing what the person who approved the payment actually had in front of them.
One assumption inside finance teams gets in the way here more than any other. Proving the integrity of an archived invoice guarantees that the document deposited in the archive stays intact and readable over its retention period. That is downstream proof, on the invoice that entered the accounting cycle. The invoice that went through the accounting chain is one object; the courtesy PDF attached to the email is another. Invoice fraud happens in the second one, where there is no archiving, no timestamp and no record of receipt.
Mailbox copies are easy to challenge
A file pulled out of your own mailbox does not prove its own history. In the standard dispute the supplier states it sent the invoice with the same bank details it has always used, and the customer produces a message, apparently in the same thread, containing different ones. Both parties hold a PDF, and neither can demonstrate from the file alone which one was delivered. A message can be edited after receipt, technical headers can be reconstructed, and the mailbox may have been cleaned up by whoever was inside it long before anyone grew suspicious. Once the counterparty denies authorship, the folder copy drops to the level of an indication and the reconstruction has to come from a technical examination that costs time and money. The procedural mechanics are covered separately in the piece on when the other side challenges the email.
Bank, insurer and supplier each need a different reconstruction
Four incompatible accounts of the same email exchange end up in the same file. This is not bad faith. Each party defends its position with the material it holds, and the question of whether the debtor discharged its obligation by paying an apparent creditor resurfaces every time the supplier asks to be paid a second time. The only party that needs to prove the context in which the message was received is the paying company, and it is also the only one that normally has nothing to show.
| Party | Position it argues | Evidence it relies on |
|---|---|---|
| Originator's bank | The transfer was authorised by the customer and the unique identifier was executed as instructed | Authorised payment order, outcome of the verification of payee check, access logs of the banking portal |
| Insurer | The event falls under an exclusion, or the declared control procedures were not followed | Bank details change procedure, out-of-band verification, timeliness of the notification |
| Supplier | It never sent that communication and the debt is still outstanding | Invoice issued and archived, its own correspondence, signature applied to the document it issued |
| Paying company | It paid in good faith on a communication that came from the supplier | Email received with its headers, attachment carrying the bank details, portal page it consulted |
What evidentiary weight emails and invoices actually carry
An unsigned email and an unsigned PDF invoice are weak documents on their own. They can be produced in proceedings, but in most European jurisdictions their weight is assessed by the court in relation to how secure, intact and unalterable they can be shown to be, and the counterparty can contest them at no cost. The eIDAS Regulation moves that balance in one specific place: under Article 41(2) of Regulation (EU) 910/2014, a qualified electronic timestamp "shall enjoy the presumption of the accuracy of the date and the time it indicates and the integrity of the data to which the date and time are bound", and Article 41(3) requires every Member State to recognise it (EUR-Lex, Regulation 910/2014).
Applied to a contested invoice, that presumption is the whole game. Whoever timestamped the email and the attachment on arrival does not have to prove the file was never touched. The other side has to overcome a presumption that it was not. How this plays out in litigation is set out in the piece on email certification as evidence in court. The practical consequence for a treasury team is short: printing the message decides nothing, because the supplier only has to say it never sent it.
What it takes to prove which version of the document is the original
Proving which version of an invoice is the original takes four elements, and all four have to exist before the dispute starts. The first is integrity: a cryptographic hash computed on the file, which makes any later change apparent. The second is a trusted date, since a qualified electronic timestamp binds that content to a moment that holds up against third parties, which the clock in a mail client does not. The third is provenance, taken from the technical headers that describe the route the message actually travelled rather than the display name of the sender. The fourth is context: what was visible at the time of receipt, including the supplier portal. These are the same properties ISO/IEC 27037 sets out for the identification, collection, acquisition and preservation of digital evidence (ISO/IEC 27037:2012). None of the four can be recovered afterwards. An examination commissioned months later works on whatever survived in a mailbox that has since been cleaned, restored or migrated.
One point almost nobody spells out. A digital signature applied by the supplier to the invoice it issues protects the outgoing document and attests where it came from. It says nothing about which email the customer received, or which attachment was on screen when the payment was approved. The signed document and the paid document can be two different files. In an IBAN swap they nearly always are.
| Source | Integrity | Date enforceable against third parties | Provenance | Context of receipt |
|---|---|---|---|---|
| Copy saved in the mailbox | No | No | Contestable | No |
| Message sent to the supplier after the event | Yes, on the message sent | Yes, on the sending | Yes, on the sender | No |
| Compliant archiving of the invoice | Yes, from deposit onwards | Yes, on the archived document | No | No |
| Supplier's digital signature on the invoice it issues | Yes, on the signed file | Only with an associated timestamp | Yes, on the issuer | No |
| Certification of the email and attachment on receipt | Yes | Yes | Yes, with the headers acquired | Yes |
Companies use TrueScreen to capture the communication that triggered the payment with evidentiary weight, so that a version exists which can be produced later rather than reconstructed after the fact.
What it means to certify a payment email and invoice at source
TrueScreen, the Data Authenticity Platform, certifies the email received and its attachment at the moment they arrive, binding a cryptographic hash to a qualified timestamp on the exact version the company received. Certifying at source means fixing the document as it enters, instead of reconstructing it once the dispute is already open. What gets certified is not only the PDF: it is the email with its technical headers, the attachment carrying the bank details and, where the invoice is downloaded from a supplier portal, the page as it appeared that day. The qualified timestamp and the electronic seal are delivered by a qualified trust service provider integrated into the platform. TrueScreen does not issue qualified certificates: it applies a third party QTSP's seal to content acquired with forensic methodology. Date, time and integrity of the received version stop being the company's assertion and become something an expert can verify.
The first object to fix is the message itself. Applying a qualified electronic timestamp to the email and the attachment makes the date of receipt enforceable against third parties. Alongside the content, the route is recorded, which is the chain of custody of an incoming message, because a technical expert will ask where it came from as well as what it said. Where invoices are pulled from a vendor portal rather than emailed, the third object matters just as much: capturing the supplier portal page as evidence preserves a screen that will have changed by the time anyone asks about it.
In practice it looks like this. An accounts payable manager receives a change of bank details from a long-standing supplier. Before passing the amendment to the ERP master data, they certify the email with its headers and the PDF attachment. The callback, made to the number taken from the signed contract rather than the one in the message, establishes that the supplier sent nothing. The certification is already in hand, and becomes the technical annex to the police report and to the insurance notification, carrying a date that precedes the discovery of the fraud. The same principle extends to certified email with legal value across all inbound correspondence.
The overseas supplier and the urgent request during the summer shutdown
Two recurring situations show where the control breaks. In the first, an overseas supplier announces it has moved to a new bank and a new IBAN in a different country. Since 9 October 2025 every payment service provider in the euro area has had to offer verification of payee free of charge, checking the name given by the payer against the holder of the destination IBAN before the payment is authorised (European Commission). The check catches the crude cases. Where the account is held under a name close to the supplier's, it returns a partial match and hands the decision back to a person. From that moment there is a documented instant at which the company was warned and chose. If the name did not match and the payment went out anyway, the company's position is worse, unless it can show which communication it relied on.
In the second, the request arrives in mid-August. The finance manager is on leave, the file is with a stand-in, the message has the right tone and quotes a real purchase order. The CEO fraud and CFO fraud variants add a confirming phone call, and that call can now use payment requests made with a cloned executive voice. Europol's IOCTA 2026 notes enhanced realism in BEC and CEO fraud driven by generative AI (Europol, IOCTA 2026), and the FBI recorded more than USD 30 million of BEC losses involving AI in 2025. Telling staff to watch for clumsy English is no longer a control.
Setting up a control on recurring financial communications
A workable control means fixing, in a verifiable way, the handful of events that will make up the file if they are ever contested. No rule currently obliges a company to document an IBAN check on every invoice, but the procedure declared to the insurer and the reconstruction the bank will ask for both assume a trace of that check exists.
| Point in the purchase-to-pay cycle | What gets fixed | Why it matters later |
|---|---|---|
| Request to change bank details | Email received, with headers and attachment | It is the document the payment decision rests on |
| Callback on an independent channel | Dated outcome, filed against the supplier record | Shows the declared procedure was followed |
| Invoice downloaded from a vendor portal | Capture of the page as it was displayed | Portals change and the screen cannot be reproduced |
| First payment to a new IBAN | Payment order and verification of payee outcome | Documents the decision taken after the warning |
A control like this is built by certifying recurring financial communications with TrueScreen as they arrive, not only once suspicion has surfaced. At the volumes of an industrial group, picking messages by hand does not hold, which is why automating certification of inbound mail on accounts payable and treasury mailboxes is the practical route. The cost of doing it is known and recurring. The cost of not having done it shows up once, and it equals the invoice.
