Prevent digital bank fraud: protect your SEPA payments with hash codes

A hash code tells you whether a SEPA payment file has changed between its creation in IFS and its arrival at your bank. With Eqeep’s hash code solution, IFS calculates the code as it creates the file, and the bank recalculates it on receipt. If the two codes match, you release the payment. So you catch an account number replaced in the file before the money is gone.

In this blog, Silvester Jansen, consultant at Eqeep, explains how that solution works.

How can a payment file change on its way to the bank?

With SEPA, payment files moved to XML. The format is flexible, but also fairly easy to modify, even with limited technical knowledge. IFS generates payment files, but it does not automatically protect them against tampering.

Payment files often sit in shared folders or take various routes to the bank. At that stage, cybercriminals can change account numbers.

The file’s own control fields will not catch it. A SEPA payment file (format pain.001) states the number of transactions and sometimes a control sum. According to ING’s format description for SEPA Instant Credit Transfers, that control sum is the total of the amounts. Swap one account number and neither the count nor the total changes.

In the old Dutch CLIEOP format, many companies also added up the account numbers, partly for their auditor. The European XML format has no such control, notes the Dutch Payments Association (Betaalvereniging Nederland). In its place, the association recommends a hash code over the whole file.

We once had a client who was hacked, and their operations were at a standstill for two to three months. Criminals got hold of their data, and recovering from the damage took months. Read how to keep your IT environment and business systems available.

How does a hash code work as a digital fingerprint?

To solve this problem, we at Eqeep developed a solution based on hash codes. A hash code is a short code calculated from the full contents of the payment file. The association’s guidance on hashing SEPA files calls it the digital equivalent of a fingerprint. Change a single character and the hash code changes completely.

The technique uses the SHA-256 algorithm, defined in the Secure Hash Standard (FIPS 180-4) of the US standards body NIST. Dutch banks recognise the standard too. The Dutch Payments Association chose SHA-256 for checking payment files.

What does a hash code in IFS give you?

A hash code for your SEPA payments has three advantages:

1. Better control: the hash code is created together with the payment file, directly in your IFS system.
2. Efficiency: the hash code is in IFS straight away, ready to compare with the code the bank calculates.
3. Time saved: no separate system generates the codes, as it all happens automatically within IFS.

How does it work in practice?

When you create a payment file in IFS, our solution automatically generates a hash code, which appears in the file’s tracking information. Your bank has to calculate and show its own code on receipt. If the two codes match, the file has not been altered and you authorise the bank to process the payment.

The association’s 2015 guidance mentions a screen after upload or a text message. Ask your bank whether it offers this. Always compare through a separate channel. Never send the code with the file, or whoever intercepts it can change both.

The association also advises storing the code so that it is virtually impossible to change. In Eqeep’s solution, the code sits in the payment file’s tracking information in IFS. Record who can view and change it.

You decide who uploads the file, who compares the codes and who authorises the batch. The association recommends spreading those tasks across several people.

The solution is available for IFS Applications 10 and IFS Cloud. It is most valuable when you send payment files to your bank without cryptographic signatures and an end-to-end SSL connection.

What does your bank already check?

The name behind the account number, but not whether the file is still the one IFS created. Since 9 October 2025, euro-area banks have checked the payee’s name against the IBAN on every euro credit transfer. This Verification of Payee comes from EU Regulation 2024/886. If the name does not match, the bank warns you before you authorise.

Febelfin, the Belgian financial sector federation, calls this extra protection against mistakes and certain types of fraud. For a batch, your company may switch the check off, and back on later.

The check also compares the name and IBAN as they appear in the payment order. If someone replaces both in the file with those of an account they control, the result is a match. Ask your bank whether your batches run with or without the name check.

Which rules should you set in IFS?

Who changes supplier bank details, who checks that change and who releases payments. If a false account number is already in IFS, the hash code covers a file that is already wrong.

A false account number can come in through invoice fraud. Fraudsters intercept a genuine invoice and replace the bank details with their own, Febelfin explains. In CEO fraud, they pose as the CEO and ask staff for an urgent, secret payment.

Febelfin and the Dutch Payments Association recommend similar measures:

• Separate the duties. Whoever changes supplier bank details does not release payments.
• Check every new account number. Call the supplier on a number already in your records, not the one on the invoice.
• Take the account number from supplier master data, with no manual edits in the payment.

In IFS, only authorised invoices can go into a payment proposal, and the proposal must be acknowledged before IFS creates the file. If an invoice carries its own payment instructions, IFS always uses them, even when the supplier has a different default. So agree who may enter those instructions.

In the Segregation of Duties analysis in IFS Cloud, your application manager records which duties conflict, with the severity Warning or Not Allowed. The analysis shows which users can still reach both duties. The History Log records the old and new value of each chosen field, with user and time stamp. Switch it on for supplier bank details.

The TRAILD add-on checks supplier bank details before payment and alerts you to changes. Read how Eqeep and TRAILD handle purchase invoices in IFS Cloud.

We map with you where your payment file sits, who can reach it, who changes bank details and who releases payments. Start with an analysis.

What does e-invoicing mean for the security of your payments?

E-invoicing leaves the risk of a false account number unchanged. According to Febelfin, invoices between businesses established in Belgium have in principle had to go through Peppol since 1 January 2026. Its invoice fraud advice still applies. An e-invoice can still carry a fraudster’s bank details, so the checks above apply.

I covered the rules in my previous blog on e-invoicing.

When does a hash code add little?

When your payment files already travel from your ERP system to the bank with cryptographic signatures. According to the association, banks and large customers often work that way. That brings costs, vendor work and certificate management. Where that is not feasible, the association recommends the hash code.

One hash code from IFS to the bank also fails when a service bureau edits the file. Every change, even a removed space, produces a different code. The association then recommends a separate code for each link in the chain.

With a multibank portal, the association says the code is checked only up to the portal. From there, the banks’ secure channels take over.

Questions about SEPA payments and hash codes

What is a hash code for a SEPA payment file?

A short code calculated from the full contents of the payment file, like a digital fingerprint. Eqeep uses SHA-256, the algorithm the Dutch Payments Association recommends. If one character in the file changes, the code changes.

Isn’t the bank’s name check enough?

Not always. Since 9 October 2025, banks in the euro area have compared the payee’s name with the IBAN. For a batch, your company can switch that check off. And if the name and IBAN in the file are replaced together, the check can still return a match.

What should you do if the hash codes don’t match?

Don’t authorise the batch. According to the Dutch Payments Association, the file may have been changed after it was created. You can delete it at the bank without processing it.

Discuss your IFS question

Tell us where you stand with IFS. You get one conversation and a clear next step. Eqeep implements the hash code solution in IFS Applications 10 or IFS Cloud. Discuss your IFS question