Since 9 October 2025, banks in the euro area compare the payee name entered with the name the IBAN is held under before every credit transfer. In a private person's online banking, that is a notice before sending. In a business that hands a payment run from accounting or its ERP system to the bank every week, it is a new response per payment for which there is usually no place: no field in the supplier master, no rule in the payment proposal, no person who clarifies a mismatch. The response then stays a notice on the screen that someone confirms or clicks away, and the real question stays open: does the money reach the right payee? This article does not explain the bank function but the process behind it - from the account holder name as a master data field of its own to the block on a mismatch and the pre-check for bulk orders. Where your own payment path has gaps today is shown by a process analysis before anything is rebuilt.
Key takeaways
- Since 9 October 2025, the bank in the euro area checks before every credit transfer whether name and IBAN belong together. A warning does not stop the payment, though: the payer can still release it.
- Credit transfer fraud losses in the EEA reached 2.2 billion euros in 2024 (ECB and EBA); around 85 percent of that was borne by the payers themselves, mostly after being deceived.
- The account holder name belongs in the supplier master as a field of its own, next to the company name. Only then does the name in the payment order match the account and the bank's response become traceable.
- A mismatch blocks the payment until it is clarified. Clarification means a call-back to a known number from the master, and every change of bank details is confirmed by a second person.
- Anyone submitting bulk orders without verification of payee (Article 5c(6)) deliberately waives the bank's check and needs a pre-check of their own in the payment run before release.
What the bank has checked since October 2025
The obligation is set out in the SEPA Regulation, specifically in Article 5c of Regulation (EU) No 260/2012, inserted by Regulation (EU) 2024/886. Under it, the payer's bank checks whether the payee name provided matches the IBAN. The check runs immediately after the payee details have been entered and before the payer is able to authorise the transfer, regardless of the channel through which the order arrives. For paper-based orders it applies on receipt, provided the payer is present. Banks based in the euro area had to offer the service by 9 October 2025 (Article 5c(9)); for banks in member states outside the euro area the date is 9 July 2027.
The check comes without an extra fee: under Article 5b(2), the services in Article 5c are provided free of charge to all payment service users. Anyone who waives the check therefore saves no fees, only work in the payment run - and that work is what this article is about.
Under Article 5c(1), the result has three main outcomes. If name and IBAN match, there is no warning. If they are a close match, the bank shows the name that belongs to the IBAN (Article 5c(1)(a)). If they do not match, the bank says so and points out that the money could go to an account whose holder is not the intended payee. If the payee is a legal person and the channel offers it, the check can also run on other data instead of the name, such as a tax number, the European Unique Identifier EUID or a Legal Entity Identifier LEI.
| Response | What the regulation provides | What happens in the payment run |
|---|---|---|
| Match | No warning; the order can be authorised without a notice. | Payment stays in the run, result and date are written back to the supplier master. |
| Close match | The bank shows the name that belongs to the IBAN provided. | Payment is held until someone has compared the name shown with the master. |
| No match | The bank warns that the money could go to a different account holder. | Payment is blocked; clarification by call-back to a known number. |
| Check not possible | Not a separate case in the regulation; bank responses can still include it, for example when the payee's bank does not respond. | Treated like a mismatch until the bank details are confirmed. |
Three further paragraphs matter for the business process. Article 5c(5) states that the check must not prevent the payer from authorising the transfer: the bank warns, it does not stop. Paragraph 7 requires the bank to point out the risk with every warning and to inform about the consequences for liability and refunds if a warning is overridden. And Article 5c(8) provides that the bank is not liable for transfers to an unintended payee if it has met the requirements of the article. Taken together: the bank supplies the information, the decision and its consequences lie with the business. Where the warning is meant to hold a payment, your own process has to do it.
What the check does not do
Why the check belongs in the business process
The figures behind the rule are clear. Reported payment fraud in the European Economic Area rose from 3.5 billion euros in 2023 to 4.2 billion euros in 2024 (ECB and EBA). For credit transfers, losses in 2024 were 2.2 billion euros, 16 percent more than in the previous year (ECB and EBA). Around 85 percent of these credit transfer losses were borne by the payers themselves, mainly because they had been tricked into initiating the payment themselves (ECB and EBA). Unlike a misused card, strong authentication does not help here: the transfer is properly authorised, just to the wrong account.
For businesses, the typical case is not the call to a private customer but the message about changed bank details: an email in the name of a supplier, an invoice with a new IBAN, a letter with a genuine-looking letterhead. Cases like these belong to the kind of deception in which the business initiates the transfer itself. How such a message stands out in the inbox before someone copies it into the master is described in From a shared mailbox to a traceable case.
In the payment run of a mid-sized business, the hand-over to the bank often looks like this: accounting or the ERP system creates a payment proposal from the items due, someone reviews it, the payment file goes to the bank and is released in the corporate banking portal. Verification of payee happens at the very end, in the bank's portal. Everything it finds therefore arrives at a point where nobody has the supplier master, the open invoice and the supplier's history in front of them. The business process has to create the way back: from the response in the bank portal to the supplier, to the invoice and to the person who can clarify.
Speed is the other factor. The same regulation also governs instant credit transfers: the payee's bank has to make the amount available within ten seconds of receiving the order (Article 5a(4)(c)). A call-back to the supplier after payment then comes too late to stop the money. The check has to come before release, and it has to be anchored in the process, not in the memory of individual people.
The account holder name as a master data field of its own
Not every warning in the payment run points to fraud. Often the cause lies in your own master data. It holds the name under which purchasing knows the supplier: a short form, a brand, a site name, sometimes with additions for searching. The account, by contrast, is held under the full company name with legal form or, for sole traders, under the owner's first and last name. If the master name goes unchanged into the payment order as the payee name, the check returns "close match" or "no match" for such suppliers run after run, although everything is correct.
The result is warning fatigue. Anyone who clicks away the same harmless notices every week will at some point also click away the one that is not harmless. A check that fires too often without reason protects less than one that fires rarely and is then taken seriously. The first lever is therefore not the block but a master that matches the account.
The remedy is a field of its own: the account holder name per bank account, separate from the company name and from search terms. It is maintained the way the bank holds it, and it is what goes into the payment order. The field carries a date and an origin: which bank confirmation, which call-back, which bank response it comes from. And as with the IBAN, a change needs a second person. How mandatory fields and approvals in the master can be set up properly is described in Getting master data in order.
Field Content and rule
Company name (master) Supplier B
Account holder name Supplier B GmbH, as the bank holds it
IBAN DE.. .... .... .... ..77 20
Valid from Date of the confirmed change
Origin Bank confirmation, call-back, bank response
Verified by Call-back to a number from the master
Entered by Person 1
Confirmed by Person 2, not the same as person 1
Last bank response close match, with date
Status active / under review / blockedWhere the supplier master lives in several systems, such as ERP, accounting and a purchasing portal, the field has to mean the same in all of them. Otherwise a nightly sync overwrites the verified account holder name with the short form from purchasing, and the warnings are back the next morning. Which system holds the leading master and in which direction data flows is a question of data integration, not of the person running the payment run.
Storing the check result per payment
The bank's response is information about a single payment at a specific point in time. If it is only shown on screen and confirmed, it is lost afterwards. Stored as a record per payment - payment, supplier, IBAN, name submitted, response, name shown, time, decision, person - it becomes the basis for three things: evidence in the individual case, maintenance of the master and analysis across many runs.
How the response gets into your own system depends on the bank and the channel. Some corporate banking portals only display it, others make it available for retrieval, and with file-based hand-over there is sometimes a response before final release. Where no automatic return path exists, a status field in the payment proposal set by the releasing person is enough to start with. Where a return path exists, it can be connected directly to the payment run via integrations, so nobody has to retype results.
Response as a record
One entry per payment with response, name shown, time and decision. It stays with the payment and can be presented when auditors or the bank have questions.
Write-back to the master
Confirmed matches set the check date and account holder name on the supplier. New names from a close match only enter the master after comparison and a second person.
Analysis per supplier
How often did which supplier get which response? Repeated mismatches show maintenance needs, a sudden mismatch for a previously unremarkable supplier is a warning sign.
A few metrics are enough for the analysis: the share of payments per response type, the number of open clarification cases and how long they have been waiting, the number of overridden warnings with a reason. Viewed monthly, they show whether master data maintenance is working and whether the block holds in daily work. How such metrics can be built from existing data is covered under metrics and reporting.
A mismatch blocks the payment until clarified
The regulation deliberately leaves the payer the choice: verification of payee must not prevent them from authorising the transfer (Article 5c(5)). For a private person that makes sense. For a payment run with many items it means that the decision on every mismatch lies with the person sending the run - under time pressure, at the end of the day, perhaps with a discount deadline looming. The block therefore belongs not in that person's attention but in the process: a "no match" response takes the payment out of the run until it is clarified.
Step 1: Hold the payment
The payment leaves the payment proposal and gets the status blocked. The other payments in the run carry on; the block affects this one item and the supplier, not the whole run. At the same time a clarification case is created with response, amount, due date and name shown.
Step 2: Call back on a known number
Clarification happens with the supplier, using a phone number that was in the master before the incident or comes from an independent source, such as the contract. The number in the email with the new bank details is exactly the one a fraudster could control.
Step 3: Record the result
Who called whom and when, what was confirmed, which account holder name applies? That is a record on the clarification case, not a note in someone's head. Later it is the evidence that the warning was not simply overridden.
Step 4: Change the master with a second person
If the call-back shows that the master is wrong or outdated, one person changes the account holder name or bank details and a second confirms the change. Whoever works on the clarification case does not confirm their own change.
Step 5: Release in the next run
The blocked payment does not bypass the run as a manual transfer; it enters the next payment proposal with the corrected master and passes through the bank's check again. For urgent cases there is an extra run, but with the same rules.
The payment leaves the payment proposal and gets the status blocked. The other payments in the run carry on; the block affects this one item and the supplier, not the whole run. At the same time a clarification case is created with response, amount, due date and name shown.
Clarification happens with the supplier, using a phone number that was in the master before the incident or comes from an independent source, such as the contract. The number in the email with the new bank details is exactly the one a fraudster could control.
Who called whom and when, what was confirmed, which account holder name applies? That is a record on the clarification case, not a note in someone's head. Later it is the evidence that the warning was not simply overridden.
If the call-back shows that the master is wrong or outdated, one person changes the account holder name or bank details and a second confirms the change. Whoever works on the clarification case does not confirm their own change.
The blocked payment does not bypass the run as a manual transfer; it enters the next payment proposal with the corrected master and passes through the bank's check again. For urgent cases there is an extra run, but with the same rules.
Close matches deserve a separate, lighter lane. Often all that is behind them is a different spelling: a missing legal form, an abbreviated suffix, an umlaut in the master and its transliteration on the account. The regulation does not define how large a difference may be for a name to count as a close match. That is why the name shown belongs in the record, so that a person can compare it with the master. If it fits, it is adopted as the account holder name, again with a second person, and the next payment goes through without a query. In process automation this lane becomes a status of its own, separate from real mismatches, so that clarification cases are not buried under spelling variants.
Who may override a warning?
Changing bank details: second person and call-back
Verification of payee applies at the end, when the payment is sent. The cause of a loss often lies earlier: on the day a new IBAN is entered in the supplier master. Once it is there, the run pays the wrong account in good order, and if the fraudster also knows the name, the bank may even report a match. That is why changing bank details is among the processes with the strictest rules in accounts payable:
- No change based on an email alone. A message about a new account is a reason to check, not the check itself, even if it comes from a known address: supplier mailboxes can be taken over.
- Call-back to a number from the master or the contract, not to the number in the message. Who was called and what was confirmed is recorded on the case.
- Entry and confirmation by two different people, enforced in the system and not just written down as a work instruction.
- New bank details get an observation period: the first payment to the new account runs individually and with verification of payee, not in the bulk order.
- Every change is traceable with old and new value, date, origin and the people involved, for your own control as well as for external audits.
A second look goes to duplicates. The same supplier under two supplier numbers is a way in: the bank details are changed in the second, rarely used record, and the next invoice is posted there. A rule that flags the same IBAN for different suppliers and different IBANs for the same name catches both; how to find such duplicates is described in Finding and merging duplicates. Because new bank details can also arrive with an invoice, checking the invoice is part of it: an IBAN on the invoice that does not match the IBAN in the master is a finding in the three-way match of invoice checking, not a reason to quietly adjust the master.
Bulk orders: waive only with a pre-check of your own
Article 5c(6) allows payment service users who are not consumers to waive verification of payee for bulk orders. The waiver can be withdrawn at any time, and under paragraph 7 the bank must point out, even with such a waiver, that the money could go to someone other than the intended payee. The rule is a relief for businesses with many payments, not a free pass.
For a business with long payment runs, waiving is the obvious choice: a check with a response per item requires someone to look at every mismatch before the bulk order is sent. How banks technically offer the check for bulk orders - as a response before release, as a view in the corporate banking portal or only for single payments - differs by institution and channel. The question for your own bank is therefore not only whether a waiver is possible, but in what form the responses arrive if you do not waive.
Waiving gives up a check without removing the reason for it. The replacement is a pre-check of your own in the payment run that runs before the bulk order is released and takes out the items where a check by the bank adds the most. The rules are simple and can be computed from the master and the stored responses:
Rule before releasing the bulk order Consequence
IBAN changed since the last run hold payment, call back
Account holder name empty in master single payment with bank check
Last response: no match blocked until clarified
Last response: close match compare names, then release
Supplier newly created (period per policy) second approval
Same IBAN for two suppliers hold, check for duplicate
Amount above threshold per supplier single payment with bank check
No rule triggered stays in the bulk orderEverything the pre-check takes out goes as a single payment with verification of payee or into clarification. The rest runs as a bulk order, in the knowledge that these items have been confirmed before and nothing has changed since. The pre-check is also the right place for the second safeguard in the payment run, the check for duplicate payments of the same invoice, as described in Preventing duplicate postings.
| Aspect | Single payment with check | Bulk order with waiver | Bulk order with pre-check |
|---|---|---|---|
| Check of name and IBAN | by the bank, per payment | none, deliberately waived | in your own system, from master and earlier responses |
| Response on mismatches | before release, per item | none | before release, only for conspicuous items |
| Effort in the run | high with many payments | low | low, the effort lies in master data maintenance |
| Changed bank details | warning if the name does not match | only noticed if your own process catches them | taken out before release |
The waiver has a downside on liability. Under Article 5c(8), the bank is not liable for transfers to an unintended payee based on an incorrect unique identifier, provided it has met the requirements of the article. Anyone who deliberately waives the check or overrides a warning generally bears the risk in such cases themselves; the bank has to explain the consequences under your own contract as required by paragraph 7. That makes it all the more important that your own process can be evidenced: which rules the pre-check applies, who set them, who may lift a block. That belongs in the process documentation like any other part of payments.
What a business can prepare itself
Getting started needs neither new software nor a rebuild of accounting. Four steps can be done with existing tools and provide the basis for any later automation:
- Analyse the master: for how many active suppliers is there an account holder name that may differ from the company name? How many bank details were changed in the last year, and can you see for each change who confirmed it? The answers are numbers, not estimates.
- Collect responses: gather the bank's warnings and notices from recent runs, as far as the portal shows them or delivers them as a file. Even a simple list shows whether the issue is spelling or real mismatches.
- Define roles: who clarifies a mismatch, who changes the master, who confirms, who may override a warning? Four roles, at least two people, set down in writing.
- Clarify the channel: discuss with the bank how the payment run is handed over today, whether verification of payee is active for bulk orders and in what form the results can come back.
The first step changes nothing yet
How much effort is involved depends on the sector. In wholesale, with many suppliers, changing bank details and high individual amounts, the pre-check pays off early; typical processes there are covered under processes in wholesale. In public administration, refunds and payments to private individuals come on top, where spellings of names easily diverge; there, the lane for close matches comes to the fore. More on the processes there under processes in administration.
The next steps in payments
The way from a clicked-away notice to a checked payment can be taken in stages, each with its own benefit and without ongoing payments coming to a halt:
- Stage 1 - measure without intervening: analyse the supplier master and the bank responses from recent runs. The result is a number per response type and a list of suppliers without an account holder name.
- Stage 2 - complete the master: create a field for the account holder name, carry origin and check date, changes to bank details and names only with a second person.
- Stage 3 - block and clarify: store responses per payment, block mismatches, clarification case with call-back and note, release in the next run.
- Stage 4 - pre-check and write-back: rules before releasing the bulk order, write-back of confirmed names to the master via data integration, analysis per supplier.
PSPs shall provide PSUs that are not consumers with the means to opt out from receiving the service ensuring verification when submitting multiple payment orders as a package.
To put the effort in context: a process analysis starts at 1,900 EUR net, delivery per automation or interface at 4,900 EUR net, ongoing support at 190 EUR net per month. Prices as of September 2026. The ongoing services can be cancelled monthly; there is no minimum term. The overview is on the pricing page, and a first conversation can be arranged via contact. If you want to put other evidence duties in order at the same time, see the articles Safety briefings scheduled and evidenced and Unused leave: the employer notice before it lapses.
Sources and legal basis
Related Articles
Interim Payments and Variations on Building Sites
How a stage of completion becomes an interim invoice, why a variation is a case with a deadline of its own, and how that produces a final account that can be checked without rework.
Shift rosters that check rest periods upfront
How rest periods, working time limits, qualification and availability are calculated as rules while the roster is built - and how plan and actual finally come together.
From shared mailbox to a traceable case
A shared mailbox starts deadlines nobody ordered. How incoming messages become cases with an owner, a deadline and a filing location, and what the law expects.