Email fraud cases

Over $120 million sent to the wrong accounts A supplier impersonation case

A genuine invoice still needs a verified payment destination.

The equipment has arrived. The invoice matches the contract. Even the supplier name in the email is familiar. What else does the finance team need to check? Whether the account receiving the money is actually authorized to collect that payment.

A supplier impersonation scheme led two US internet companies to send more than $120 million to accounts controlled by a fraudster. The case shows why the email sender, the contracting company, and the bank account need to be checked together.

The scheme ran from 2013 to 2015; sentencing followed in 2019

On December 19, 2019, the US Department of Justice announced a 60-month prison sentence for Lithuanian national Evaldas Rimasauskas. In a business email compromise, or BEC, scheme, he had tricked two US companies into transferring more than $120 million to accounts he controlled.

  1. 2013–2015
    Supplier impersonation

    Payments for genuine business transactions were directed to accounts controlled by the attacker.

  2. March 20, 2019
    Guilty plea

    The announcement at this stage described transfers totaling more than $100 million.

  3. December 19, 2019
    Five-year prison sentence

    The sentencing announcement put the total transferred at more than $120 million.

The timeline recorded in the Justice Department’s guilty plea and sentencing announcements

This article uses the amount in the later sentencing announcement. It describes the total the victims were induced to transfer, not their final net loss or the amount recovered. DOJ guilty plea announcement, March 20, 2019 ↗ DOJ sentencing announcement, December 19, 2019 ↗

The useful question for a finance team is what evidence justified the payment. A genuine invoice can still be diverted. When the destination account changes, that change needs its own verification.

A different company used the same supplier name

According to the announcement, Rimasauskas registered a company in Latvia under the same name as an Asian hardware supplier and opened accounts in Latvia and Cyprus in that company’s name. Emails impersonating the supplier’s staff directed legitimate payments to those accounts.

  1. 01Impersonation emails

    Directed payments to the attacker’s accounts.

  2. 02A separate company with the same name

    Provided the name under which the receiving accounts were held.

  3. 03Forged invoices, contracts, and letters

    Were submitted to banks to support the large transfers.

Three elements described in the public account. This is not a reconstruction of the victims’ internal approval process.

The forged documents were submitted to banks. That does not establish that the victim companies used those documents in their own approval process. The announcements do not identify the victims by name or disclose their approval procedures or email authentication results. The scheme described by the DOJ ↗

A matching name does not establish the contracting party

A company name is a label; a legal entity is the party that holds rights and obligations under a contract. In daily work, people use the supplier’s name. At payment time, they also need to establish which entity the contract names. Separate companies can share a name across countries, and a corporate group can contain several distinct legal entities.

A familiar beneficiary name is therefore only part of the check. A different registration country, company identifier, or contractual relationship calls for review. An overseas account is not automatically fraudulent, either: an overseas subsidiary or authorized collection agent may legitimately receive payment. The relationship needs evidence.

A company registry can help confirm that an entity exists. It does not, on its own, prove that the entity may collect money under your contract. The same applies to a bank letter or a PDF bearing a company stamp. Compare it with the contract and verified supplier records, and check where the document came from.

A worked example: a valid invoice, an unverified account

The following company names, identifiers, and amounts are fictional. This example illustrates a finance workflow; it does not recreate the victims’ transactions or approval process.

Gaon Technology has bought equipment from Haneul Parts. Purchase order PO-217 is for $48,000. Purchasing has confirmed delivery, and finance holds an unpaid invoice. The day before payment is due, someone who appears to be the supplier’s contact sends this message:

The email includes bank details and company registration documents. The beneficiary name matches the English company name on the contract. Placing the request beside the existing supplier record reveals the differences.

Scroll sideways to read the full table.

A fictional payment comparison. Registration numbers and account labels are illustrative.
ItemPreviously verified supplier recordNew email request
Legal nameHaneul Parts Ltd.Haneul Parts Ltd.
Registration countrySouth KoreaThe Netherlands
Company registration numberK-101N-902
Beneficiary accountPreviously approved account ANewly supplied account B
Purchase order and amountPO-217 · $48,000PO-217 · $48,000

The last row matches, so the team may be satisfied that the invoice relates to equipment it bought. Three other rows have changed. The invoice has been verified; the new payment destination has not. A genuine purchase does not establish that account B is an authorized destination.

Two approvers can still rely on the same false evidence

Suppose an employee records “name and amount match,” and a manager rereads the same email and attachments. Two people have checked the request, but all their evidence came from one message. If that message is fraudulent, the second review may simply repeat the first mistake.

The second approver needs independent evidence for the change: who contacted the genuine supplier, how that contact was established, how the new entity relates to the contract, and whether the final payment details match the verified instruction.

  1. Pause the payment and the account change

    Keep the existing supplier record. Save the new request alongside it and mark the differences. Approval of the invoice and approval of the changed account should remain separate decisions.

  2. Contact the existing contractual counterparty

    Use a previously verified phone number or contact route, rather than the signature in the new email. Confirm the purchase order, the new beneficiary’s registration details, and the account change. Asking only “Did you send an email?” leaves too much unresolved.

  3. Check the authority for a different entity to collect payment

    Even if the genuine supplier confirms the request, purchasing or legal staff should review the contract change or collection authority. A single email should not silently replace the party entitled to receive payment.

  4. Compare the approved details with the actual transfer

    The final approver reviews the contact record and the basis for approving the entity and account. They also compare the beneficiary and account entered into the payment file or banking screen with those approved details.

In this fictional example, the established contact says neither the collecting entity nor the account has changed. Finance stops the registration of account B and passes the original email and attachments to security. After checking the invoice and ruling out duplicate payment, it processes the genuine equipment payment through the existing approved account. The suspicious instruction has been stopped without losing track of the legitimate invoice.

If the change is genuine, review the new entity’s contractual role before updating the account. Retain the old and new values, the verification evidence, and the approver. If the only explanation is urgency and verification remains incomplete, keep the payment on hold while checking; an unverified request does not yet establish fraud.

The FBI advises verifying payment requests and changes through another channel. This example applies that principle to the legal entity and account behind a payment. FBI guidance on preventing BEC ↗

DMARC does not verify the bank account

Could the team simply check whether DMARC passed? DMARC connects the visible From domain to an authentication result. At least one of SPF or DKIM must pass with a domain that aligns with From.

That helps recipients recognize unauthorized use of the supplier’s exact domain. An attacker’s own lookalike domain or a compromised legitimate account can still pass authentication. A dmarc=pass result supports authentication of the From domain; it does not establish the company’s identity, the contract, or the account’s entitlement to payment. The standard makes clear that passing is not a guarantee of safety, and that lookalike domains and display-name impersonation fall outside its protection. What a DMARC pass means ↗ DMARC’s scope ↗

Protecting your domain and inspecting incoming mail are separate jobs

Publishing SPF, DKIM, and DMARC for your domain helps other recipients verify mail claiming to come from you. For incoming supplier messages, your receiving service needs to inspect the supplier’s authentication results and other security signals. Setting p=reject on your domain does not by itself block emails impersonating your suppliers.

Security staff investigate authentication and the sending path; finance and purchasing verify the payment destination and the reason for a change. Connect those checks without treating a successful result in one as permission to skip the other. The public record does not include the actual email headers or DMARC settings in this case, so it cannot establish that DMARC would necessarily have prevented it.

Three checks to make before the next supplier payment

Pick one recent supplier payment. If the usual contact left tomorrow, could another employee explain why the recipient was authorized to receive the money? That question makes gaps in the process easier to find.

1. Does the supplier record identify the legal entity?

A trading name and email address may not be enough. Link the contract, registration country, company identifiers, and approved account. If a group company or collection agent receives payment, retain the authority and relationship as well. Record how the information was verified, rather than simply collecting documents.

2. What evidence supports account changes?

Review one change and the evidence each approver used. If both relied on the same email and attachments, identify where an independent check belongs. Retaining previous values and verification history also makes an erroneous or suspicious change easier to trace.

3. Can someone stop a payment and preserve the evidence?

Decide who can hold a payment and who contacts the bank if money has already moved. Preserve the time, amount, destination account, original email, attachments, and supplier-change and approval records. Do not wait until every document is collected before contacting the bank. The FBI advises immediate contact with the financial institution; whether funds can be recovered remains a separate question. FBI guidance after a fraudulent transfer ↗

For the technical checks, start with how SPF, DKIM, and DMARC work and use the DMARC rollout checklist to document your senders. For finance, a useful first step is to put one account-change request beside the existing supplier record, as in the example above.

About this article

Genharden DMARC · Updated 2026-09-22. Incident details come from the official reports linked in the article. We distinguish reported facts from unknowns and identify our suggested procedures separately.

← Back to resources