Phishing invoice scam: the paying company must absorb the loss

The bank account change scam: €30,000 nobody wants to pay

A Spanish company provides services to a client in Segarro. The job is finished, the invoice is sent by email, and weeks later a bank transfer receipt arrives. The money never does. The destination account is not theirs: it is at the same bank, but under a different account holder, and it was closed the day after receiving the funds. When the company claims payment from the client, the client forwards an email that apparently came from the Spanish supplier, announcing a change of account number. The domain was identical except for the extension. The case, worth more than €30,000, has been reported to the police and raises two uncomfortable questions: who was hacked? Who should bear the loss?

The discussion, which has gone on for several days in the forum, has shifted from the initial suspicion of a hack to an analysis of impersonation techniques. What began as an isolated case has become a familiar pattern: business email compromise (BEC) fraud, which has hit town councils, companies and the self-employed.

The modus operandi: email spoofing and mule accounts

The scam requires no great technical expertise. All it takes is registering a domain similar to the impersonated company's — changing one letter, adding a hyphen — and sending an email to the payer. In this case, the fake email reproduced the sender's name, the typeface and the address, except for the final extension. The payer, reassured by years of business relations, did not verify it through another channel. The receiving account was peine in person at a Spanish bank, the same one the supplier used, and was closed the day after the funds arrived.

The most detailed analyses suggest the attacker may have had access to one party's email for weeks. "Someone on the inside passed on the info," one participant argues, mentioning the possibility of a keylogger or a trojan on the accountant's computer. Another adds that it could also be a silent redirect configured on the hosting: all incoming email is forwarded to another address without the user noticing. The most likely victim, several agree, is the company waiting to be paid, because the attacker knew the exact moment the invoice was sent and the client's details.

There is no consensus, however. One camp argues the payer itself may have sent the fake email to divert the money into an account it controlled. Another speculates about collusion between the two companies to collect an insurance payout. And a third, simpler theory points to a disgruntled employee at the paying company who knew the ins and outs of the deal. The police investigation remains open.

Who bears the loss? The legal and commercial debate

The key question is who should shoulder the shortfall. The majority view is clear: the defrauded party is the payer, who sent the money to the wrong account without verifying the authenticity of the instruction. "Whoever made the transfer should have made sure. The domain doesn't even match," one participant sums up. For this camp, the supplier is entitled to demand payment for the services rendered; the payer must own up to its mistake and, at most, try to recover the money through incivil proceedings.

Others add nuance. Some argue responsibility is shared if it is proven that the supplier was hacked and failed to warn of the risk in time. In practice, many suppliers have absorbed losses to avoid losing clients, as a similar case in Galicia shows. The discussion has also turned to the banks' responsibility: how is it possible that a transfer of more than €30,000 to an account under a different holder at the same bank triggers no alarm? "I can't understand how, to make a transfer, they ask you for the beneficiary's name, and then that money ends up in an account under a different holder and no alarm goes off," the original poster complains.

The reality is that banks do not always check that the beneficiary's name matches the account holder on domestic transfers. For international SWIFT transfers the rules are stricter, but experts point out that verification is not automatic. The receiving bank credits the funds to the account specified, and only in cases of flagrant suspicion is the transaction returned.

The outcome: no payment and a trial in Segarro

In the end, the Segarro client refused to pay. After several conversations and kind words, he announced he would not transfer the money again and was prepared for a trial, which will presumably take place in Segarro. The Spanish company is left with an unpaid invoice and few options for recovering the amount. The original poster, who had anticipated this outcome, laments that his client — almost a friend — has lost both the money and the business relationship.

The case is not an isolated one. In recent years, identical frauds have been documented against town councils, service companies and suppliers of all kinds. The unanimous recommendation is to verify any change of bank account details through an alternative channel — a phone call, a bank certificate — before making the payment. Digital signatures and email encryption would help, but adoption remains limited. Meanwhile, scammers keep exploiting the weakest link: trust.