When a supplier sends new bank details, the first check is yours to make.

The change and the check happen at different moments.

The sequence is always the same. A supplier gets in touch to say their bank details have changed. Someone in accounts payable updates the vendor record. Two or three weeks later the payment run picks up the open invoices, builds a file, and the money goes to whatever account the record now holds. Nothing about that sequence looks unusual, which is exactly why it is the most reliably profitable attack on a finance function.

Since 9 October 2025 there has been a plausible reason to believe the problem is now handled somewhere else. Regulation (EU) 2024/886, the instant payments regulation, inserted a new Article 5c requiring every payment service provider in the euro area to offer Verification of Payee: before you authorise a euro credit transfer, your bank asks the receiving bank whether the account and the payee you named belong together, and tells you the answer. The four possible answers are a match, a close match, a no match, or verification not possible.

Read Article 5c closely and two features of it decide where your own work has to go. The first is timing. The service is performed immediately after the payer provides relevant information about the payee and before the payer is offered the possibility of authorising that credit transfer. It is welded to a payment. The European Payments Council, which owns the scheme, was asked this exact question about corporate ERP systems and answered it directly: verification cannot be decoupled from a payment transaction, and onboarding a new vendor in an ERP system is not covered, because at that moment no concrete payment is initiated. Verification happens when the first payment to that vendor is initiated, and for each one after that.

The second is the opt out. Article 5c(6) requires providers to give payers that are not consumers the means to opt out from the verification service when submitting multiple payment orders as a package. A payment run is, by definition, multiple payment orders submitted as a package. So the check that exists to catch this is available at the end of the sequence rather than at the start, and a corporate may decline it at the end as well.

That is not a complaint about the Regulation, which was written mainly with consumers in mind and has worked well there. It is a statement about where the useful work sits for a finance team. The moment a supplier bank record changes, your system is the only thing present. Everything this article suggests follows from taking that seriously, and none of it is large.

What Article 5c actually says.

The summaries circulating about this are unreliable in one specific way that is worth correcting before anything else. A great many of them describe Verification of Payee as a feature of SEPA Instant. It is not limited to instant payments. Article 5c(1) speaks of a credit transfer, and Article 5c(9) dates the whole Article. Your ordinary scheduled euro payment run is in scope on the same date as the instant one, which changes where a team would sensibly spend its effort. The table below works through the provisions that reach a payment owner, read from the text.

Two rows deserve more than a line. The first is Article 5c(1), point (b), which almost nobody writing about this mentions. Where the payee is a legal person, and the channel supports it, you may provide a data element other than the name that unambiguously identifies the payee: a fiscal number, a European unique identifier under the company law directive, or a legal entity identifier. The receiving bank then verifies the account against that element rather than against a name string. This matters because name matching is genuinely hard. The scheme rulebook sets only a minimum set of matching rules, so the algorithm belongs to each provider, and Deutsche Bank reports that writing a legal form out in full rather than abbreviating it can produce a no match on an account that is perfectly correct. An identifier sidesteps the whole category. It is only available to you if your supplier record carries one.

The second is Article 5c(8), which allocates the loss. A provider is not liable for executing a transfer to an unintended payee on the basis of an incorrect unique identifier, under Article 88 of the payment services directive, provided it has fulfilled the requirements of the Article. Where the payer provider fails to comply and that causes a defective execution, it refunds. The European Payments Council states the corporate position without ambiguity in its guidance on bulk files: there is neither increased liability nor the possibility of a liability shift toward providers, and whenever a corporate user authorises a payment, whether after processing a result or after opting out, the corporate user remains the liable party. That is the whole economic case for building the control at the change event, where it is cheap.

What a format check buys you, measured.

Before the design, it is worth being precise about the cheapest check available, because it is often mistaken for a stronger one than it is. An IBAN carries two check digits. Validating it means confirming the length matches what the country publishes in the ISO 13616 registry, then moving the first four characters to the end, mapping letters to numbers and testing that the result modulo 97 equals one. That is the test behind the IBAN checker published on this site, and we ran its own logic over a million random corruptions per case to find out exactly where it stops helping.

The first row is the reassuring one and it is worth using. A rekeyed account number with a single finger slip in it will not reach a payment file, every time, at no cost. The last row is the one to sit with. A correctly formed IBAN belonging to somebody else passes every format test that exists, because a check digit answers whether a number is internally consistent and has no opinion about who holds the account. Fraud in this area does not involve malformed account numbers. It involves perfectly good account numbers that belong to the wrong person.

So the format check earns its place as the first gate and nothing more. It belongs in the change form, running as the details are keyed, where it catches transcription errors immediately and costs one function call. Ownership is a separate question with a separate answer, and the rest of this article is about that answer.

The opt out, and how common it turns out to be.

It is one thing to know that Article 5c(6) permits an opt out and another to know what companies actually chose. Deutsche Bank published the numbers from its own EBICS channel in a flow briefing dated 9 April 2026. Of corporate SEPA credit transfer files, around 84 percent were opted out in October 2025, 82 percent in November, 76 percent in December and about 80 percent in January 2026. SEPA Instant files moved further, from 81 percent opted out in October 2025 to 67 percent in January 2026, which the briefing attributes to a greater perceived need for fraud protection on instant payments.

The reason is mostly mechanical rather than a considered risk decision. There is no common customer to bank standard for verification, only an interbank one, so treasury and ERP software has not generally embedded the extra step. Deutsche Bank notes that the German EBICS approach currently lets a corporate authorise or reject an entire payment file after seeing the results, with no option for partial automatic execution. For a team used to straight through processing, opting in can mean that one questionable line stops the whole run, which is a real cost on a real Friday.

The European Commission has confirmed that two better patterns are available, in answers 117 to 120 of its implementation questions and answers. In the first, you send a verification request file, build the payment file from the responses, and submit it. The Commission notes that in this shape a specific opt out is not needed, since you are authorising the orders on the basis of the feedback you already have. In the second, the bank runs verification from the payment file itself, executes the lines that come back as a match, and asks you to confirm only the close matches and the no matches. The Commission confirms both are possible, and notes that the ten second rule does not apply to the second one. Either is worth asking your bank about by name, because both preserve most of the automation.

One more piece of the picture, specific to Germany. A package needs more than one order in it before the opt out applies, so a file carrying a single transfer could not be opted out. Banking.Vision reports that BaFin has said in its own questions and answers that it will not object to a waiver for such files until further notice. That is useful breathing room and a thin foundation to design on, since a supervisory tolerance can be withdrawn and a rule cannot.

The practical takeaway is short. Find out which state your files are in today, ask your bank which of the two Commission patterns it supports, and treat opting in as a goal rather than a switch to flip on a Friday. Article 5c(6) gives you the right to opt back in at any time, so this is a decision you can revisit once the handling rules exist.

The record that makes the change event the control point.

Everything above points at one conclusion: the strongest available control is at the moment the bank details change, because that is the moment your own system is present and no external scheme is. The good news is that this control is small. It is a handful of fields, a rule about who may approve what, and one query. The structure below is what those fields look like when the change event carries its own evidence.

# The supplier bank change, modelled so the change event carries its own
# evidence. Identifiers and figures below are placeholders and describe no
# real organisation, supplier or account.

supplier:
  supplier_id: "SUP-20418"
  legal_name: "Norlake Components BV"        # as the receiving bank holds it
  trading_names: ["Norlake", "Norlake Parts"] # never sent in the instruction
  vat_number: "NL001234567B01"                # Article 5c(1)(b) identifier
  lei: "5493001KJTIIGC8Y1R12"                 # optional, carries a renewal date
  lei_next_renewal: "2027-03-14"

supplier_bank_account:                        # versioned, never overwritten
  - account_id: "SBA-20418-01"
    supplier_id: "SUP-20418"
    iban: "NL91ABNA0417164300"
    account_holder_name: "Norlake Components BV"
    valid_from: "2023-02-09"
    valid_to: "2026-09-18"                    # closed by the change below
    status: "superseded"
  - account_id: "SBA-20418-02"
    supplier_id: "SUP-20418"
    iban: "NL02RABO0123456789"
    account_holder_name: "Norlake Components BV"
    valid_from: "2026-09-18"
    valid_to: null
    status: "active"
    first_payment_hold_until: "2026-09-25"    # deliberate cooling period

bank_change_request:                          # separate record, separate people
  request_id: "BCR-7741"
  supplier_id: "SUP-20418"
  resulting_account_id: "SBA-20418-02"
  requested_via: "email"                      # the channel the request arrived on
  requested_by_contact: "accounts@norlake.example"
  received_on: "2026-09-16"
  requested_by_user: "ap.clerk.02"            # who keyed it
  approved_by_user: "ap.manager.01"           # must differ from the above
  approved_on: "2026-09-18"

out_of_band_verification:                     # the control the scheme cannot run
  request_id: "BCR-7741"
  method: "callback"
  number_called: "+31 20 555 0143"
  number_source: "master_agreement"           # NOT the change request itself
  person_reached: "finance director, named in the contract"
  verified_by_user: "ap.manager.01"
  verified_on: "2026-09-18"

payment_channel:                              # a configuration fact, recorded
  channel_id: "CH-EBICS-EUR-01"
  bank: "primary euro bank"
  file_type: "package of payment orders"
  vop_state: "opted_in"                       # Article 5c(6), changeable anytime
  effective_from: "2026-09-01"
  changed_by_user: "treasury.lead"

payment_verification_result:                  # stored, because none expires
  payment_id: "PMT-556213"
  account_id: "SBA-20418-02"
  result: "match"                             # match | close | no_match | not_possible
  obtained_at: "2026-09-25T08:14:00Z"
  acted_on_at: "2026-09-25T08:16:00Z"
  released_by_user: "ap.manager.01"

# The exception query. Run it before every payment run, not after an incident.

SELECT ref, reason FROM (
  -- bank details changed inside the payment window, so the change and the
  -- money movement are close enough together to deserve a second look
  SELECT a.account_id AS ref, 'account changed within 7 days of a payment' AS reason
    FROM supplier_bank_account a
    JOIN payment p ON p.account_id = a.account_id
   WHERE p.value_date < a.valid_from + INTERVAL '7 days'
  UNION ALL
  -- a change with no independent verification recorded against it
  SELECT r.request_id, 'bank change without out of band verification'
    FROM bank_change_request r
    LEFT JOIN out_of_band_verification v ON v.request_id = r.request_id
   WHERE v.request_id IS NULL
  UNION ALL
  -- the callback used a number that came from the request itself
  SELECT v.request_id, 'callback number sourced from the change request'
    FROM out_of_band_verification v
   WHERE v.number_source = 'change_request'
  UNION ALL
  -- the same person keyed and approved the change
  SELECT request_id, 'requester and approver are the same user'
    FROM bank_change_request
   WHERE requested_by_user = approved_by_user
  UNION ALL
  -- a supplier with no identifier, so only name matching is available
  SELECT supplier_id, 'no fiscal number or LEI for identifier matching'
    FROM supplier
   WHERE vat_number IS NULL AND lei IS NULL
  UNION ALL
  -- a payment released over a warning, with no rule reference recorded
  SELECT payment_id, 'released over close match or no match'
    FROM payment_verification_result
   WHERE result IN ('close', 'no_match')
  UNION ALL
  -- a channel quietly opted out of verification
  SELECT channel_id, 'payment channel opted out of verification'
    FROM payment_channel WHERE vop_state = 'opted_out'
  UNION ALL
  -- a verification result acted on long after it was obtained
  SELECT payment_id, 'verification result older than our own window'
    FROM payment_verification_result
   WHERE acted_on_at > obtained_at + INTERVAL '48 hours'
) exceptions
ORDER BY reason, ref;

Three choices in that shape do most of the work. The bank account is a versioned entity rather than a field, so a change closes one row and opens another and the history survives. The out of band verification records where the phone number came from, because a callback to a number supplied inside the change request verifies nothing and is the single most common way a well intentioned check fails. And the new account carries a hold date, so the first payment on changed details meets a deliberate pause rather than flowing with the batch on the day it is needed most.

The identifier fields are worth the effort too. A fiscal number or a legal entity identifier turns Article 5c(1), point (b) from a paragraph into something you can use, and it is the difference between a verification result that reflects reality and one that reflects how your supplier wrote its legal form. Storing the payee name as the receiving bank holds it, separately from the trading names, does the same job from the other direction.

An implementation checklist.

None of this is a programme. It is a few fields, one rule about approvers, one deliberate pause and a query on a schedule.

1. Find out today whether your euro payment files are opted in or opted out. Article 5c(6) gives you the choice and the right to change it at any time, and the answer is a setting on your channel rather than a matter of interpretation. Ask your bank which files are currently opted out and what a result would look like if you opted in. Deutsche Bank published the market picture on its own EBICS channel: around 84 percent of corporate SEPA credit transfer files opted out in October 2025 and still about 80 percent in January 2026, so the majority answer is opted out.
2. Put an identifier on every supplier record. Article 5c(1), point (b) lets you match on a fiscal number, a European unique identifier or a legal entity identifier instead of a name, where the payee provider holds the same element. That removes the whole class of failures Deutsche Bank describes, where a legal form written in full rather than abbreviated produces a no match on an account that is perfectly correct.
3. Hold the payee name exactly as the receiving bank holds it, and hold the trading names separately. The scheme rulebook sets only a minimum set of matching rules, so the same name can return a match at one provider and a close match at another. The name you send is a field worth curating rather than whatever the invoice letterhead said.
4. Version the supplier bank account rather than overwriting it. A bank detail change is an event with a requester, a channel, a date and an approver. Overwriting the field in place destroys the only record that can answer how this account got here, which is the first question anyone asks after a loss.
5. Verify the change out of band, against a source you already held. Call a number from the signed contract or the supplier master, never a number in the message requesting the change, and record who called, who answered and when. This is the control the bank scheme cannot perform for you, because at that moment there is no payment for it to attach to.
6. Give a newly changed account a cooling period before the first payment. The change event is when the risk is created and the payment run is when it is realised, and a deliberate gap between the two is the cheapest place to put a second pair of eyes. Hold the first payment on new details for review rather than letting it flow with the batch.
7. Decide in advance what a close match and a no match do, and write it down. Article 5c(5) means the result never blocks anything by itself. Treat a no match on a long standing account differently from a no match on an account changed last week, and put that difference in the rule rather than in the judgement of whoever is on shift.
8. Record the verification result against the payment, with its timestamp. No expiry period is defined for a verification, so a result has whatever shelf life you give it. Store the outcome, the date and the account version it was obtained against, and set your own window after which you would want a fresh one.
9. Run the exception query on a schedule. An account changed within the payment window, a change with no out of band verification recorded, a supplier with no identifier, a payment authorised over a no match: each of these is one row, and finding it yourself costs nothing compared to finding it afterwards.

Where this goes wrong, and how to see it coming.

The failure modes here are mostly assumptions rather than mistakes, which is good news, because an assumption can be checked in an afternoon.

• Assuming the bank now checks this for you. The service is real and it works, but Article 5c(1) ties it to a payment and Article 5c(6) lets a package submitter opt out. If your payment files are opted out, which the published market data suggests is the common case, nothing is being checked on your behalf at all.
• Reading the requirement as applying only to instant payments. Article 5c covers credit transfers, and Article 5c(9) dates the Article as a whole. A team that scopes its work to SEPA Instant leaves its ordinary scheduled euro run out of the picture.
• Expecting a liability shift. Article 5c(8) protects the provider that performed the service correctly, and the EPC states that a corporate user faces no liability shift and remains the liable party whether it acts on a result or opts out. The economics of the control sit with you, which is an argument for building it properly rather than for hoping.
• Trying to use the bank scheme to validate vendor master data. The Commission answers this at questions 117 and 118. You can agree such a service contractually, but then it sits outside Article 5c, the free of charge rule in Article 5b(2) may not apply, and you need a lawful basis under data protection law. It is a commercial conversation with your bank, not a right you already hold.
• Treating a format check as a verification. Running the IBAN through a checker proves the country length and the check digits are consistent. Our own measurements put the ceiling at roughly 1 percent of corrupted numbers passing, and a well formed IBAN belonging to a fraudster passes every time. Format and ownership are different questions.
• Letting a single transaction file decide your design. A package needs more than one order in it before the opt out applies, and Banking.Vision reports that BaFin has said it will not object to a waiver for single order files until further notice. Useful relief, and a fragile thing to build a control on.
• Overwriting the bank account field. The moment the previous value is gone, so is the ability to say when it changed, who asked and what was checked. Versioned rows cost almost nothing and are the difference between an incident you can explain and one you cannot.
• Handling a no match by hand, every time, with no rule. Deutsche Bank notes the German EBICS approach currently offers no partial automatic execution, so a file is authorised or rejected whole. Without a written rule for close match and no match, a busy day turns the control into whatever the person in front of it decides.

Data and integration considerations.

• The supplier bank account is its own versioned entity, not a field on the supplier. Give it an identifier, a valid from and valid to, the IBAN or local account details, the account holder name as the receiving bank holds it, and a status. Every change writes a new row and closes the old one, so the history is a query rather than an archaeology exercise.
• The change request is a separate record from the account. Who asked, through which channel, on what date, with what supporting document, and which internal person approved it. Keeping the request apart from the resulting account row is what lets you show that the two were handled by different people.
• The out of band verification is a first class field with its own evidence. The number called and where that number came from, the person reached, the date and the caller. A change verified against a phone number supplied in the change request itself has not been verified, and the data model should be able to tell the difference.
• Identifiers belong on the supplier, sourced and dated. A VAT or fiscal number, a European unique identifier and a legal entity identifier where one exists. Article 5c(1), point (b) can only use what you can supply, and the LEI in particular carries a renewal date that is worth holding so a lapsed record does not surprise anyone.
• The verification outcome is stored against the payment and the account version. Match, close match, no match or verification not possible, with the timestamp and the account row it was obtained for. Because no expiry is defined, the age of a result is only knowable if you wrote it down.
• The opt in or opt out state of each payment channel is a recorded attribute, not folklore. Which bank, which channel, which file type, opted in or out, effective from when and changed by whom. This is a configuration fact with a compliance consequence, and it should live somewhere a query can reach.
• Keep the name you send separate from the names you display. The legal name as the bank holds it drives the match. Trading names, brand names and the name on the invoice are useful elsewhere and harmful in the payment instruction, so store them in different fields and pick deliberately.
• Hold history rather than only current state. Which account was in force on the date an invoice was approved, which verification result was in hand when a payment was released, and what the supplier record looked like on a given day are all questions a later review can ask cheaply if the rows are versioned and expensively if they are not.

What the evidence file should contain.

The reason to keep this material is not one regulation. Supplier bank detail changes sit inside the payments control environment that internal audit, external audit and most crime insurance policies already ask about. Handled as a set of records rather than as an email thread, the change process produces its evidence as a by-product.

• The supplier bank account history, showing each version with its valid from and valid to dates and the change request that produced it.
• The change request record, showing who asked for the change, through which channel, with what supporting document, and who approved it, with the approver different from the requester.
• The out of band verification record, showing the number called, the source of that number, the person reached and the date, for each change to bank details.
• The configuration record for each payment channel, showing whether files were opted in or opted out of verification on a given date, and the warning the provider gave under Article 5c(7) when an opt out was taken.
• The verification outcomes stored against payments, showing the result, the timestamp and the account version it was obtained for, together with the rule that was applied to a close match or a no match.
• The authorisation record for any payment released over a close match or a no match, showing who released it, on what basis and against which documented rule.
• The supplier identifier record, showing the fiscal number, European unique identifier or legal entity identifier held, its source and its date, so identifier based matching under Article 5c(1), point (b) can be evidenced.
• The scheduled exception query and its results over time, showing that accounts changed close to a payment, changes without verification and suppliers without identifiers were looked for on a cadence rather than after an incident.

Questions worth asking before the next payment run.

• Are our euro payment files opted in or opted out of verification today, and who made that choice?
• When a supplier changes its bank details, does our system keep the previous account as a closed version, or does it overwrite the field?
• Can we show, for the last ten bank detail changes, who requested each one and which independent source we verified it against?
• Do we call a number from our own records, or a number supplied in the message asking for the change?
• Does the first payment on newly changed bank details go out with the ordinary batch, or does it stop for a second look?
• Do our supplier records carry a fiscal number or a legal entity identifier, so a payee can be matched on an identifier rather than on a name?
• Is the payee name we send the one the receiving bank holds, or the one that happened to be on the invoice?
• What is our written rule for a close match and for a no match, and does it distinguish a long standing account from one changed last week?
• How old is a verification result allowed to be before we would want a fresh one, given that no expiry is defined for us?
• If a payment went to the wrong account tomorrow, which record would tell us how that account came to be there?

A small control, in the one place it works.

Verification of Payee is a genuinely good piece of regulation and it has made consumer payments safer. What it does for a business paying suppliers is narrower than the headlines suggest, for two reasons that are both in the text: the check attaches to a payment rather than to a record change, and a payment run may opt out of it. Article 5c(8) and the European Payments Council between them leave the payer carrying the loss. Read as a problem, that is discouraging. Read as a design brief, it points at a control that is unusually cheap to build and unusually effective.

The control is the change event. Version the account instead of overwriting it. Make the person who keys a change different from the person who approves it. Call a number you already held, and write down where that number came from. Hold the first payment on new details for one deliberate look. Put an identifier on the supplier so the bank can match on something better than a name. Then run one query before each payment run and read what it returns. That list fits on an index card, and it covers the gap the Regulation leaves you.

The cheapest piece is also the easiest to start with today. Put a format check in the change form so a mistyped account number never reaches a payment file, and be clear with the team about what it proves and what it does not. If you want to see exactly where that line falls, the Rivane IBAN checker runs the same ISO 13616 length rule and mod 97 check digit test the measurements above came from, and it is free to use.

Sources

• Regulation (EU) 2024/886 of the European Parliament and of the Council of 13 March 2024 amending Regulations (EU) No 260/2012 and (EU) 2021/1230 and Directives 98/26/EC and (EU) 2015/2366 as regards instant credit transfers in euro, on EUR-Lex. Opened and read directly rather than through a fetched summary. Source for every normative statement here: the verification service and its timing in Article 5c(1); the identifier based matching route for a payee that is a legal person in Article 5c(1), point (b); the rule that verification must not prevent authorisation in Article 5c(5); the opt out for payers that are not consumers submitting packages, and the right to opt back in, in Article 5c(6); the warning and liability information duties in Article 5c(7); the allocation of liability in Article 5c(8); and the compliance dates of 9 October 2025 and 9 July 2027 in Article 5c(9). Recitals 21, 22 and 24 were read alongside them.
• European Payments Council, FAQ 27526, on whether a provider may send verification requests when the intention to pay is deferred, for instance during vendor onboarding in a corporate ERP system, last updated 25 July 2025. Read directly. The scheme owner states that verification cannot be decoupled from a payment transaction, that a future dated payment is verified at registration, that no expiry period is defined for a verification, and that onboarding a new vendor in an ERP system is not covered because no concrete payment is initiated at that moment.
• European Payments Council, FAQ 27286, clarifications about the provision of verification services for bulk files, last updated 17 July 2025. Read directly. Source for the four possible answers, for the fact that bulk handling sits outside the scheme and that an inter provider request always concerns a single IBAN, for the statement that a corporate user faces no liability shift toward its provider and remains the liable party whether it acts on a result or opts out, and for the EPC halting standardisation of bulk handling in the customer to provider space.
• European Commission, Clarification of requirements of the Instant Payments Regulation, the implementation questions and answers document. Downloaded and read directly at questions 117 to 120. Source for the position that the verification service is for making credit transfers and that other uses, such as checking static vendor data, can be agreed contractually but sit outside Article 5c, where the free of charge rule in Article 5b(2) may not apply and a lawful basis under the GDPR has to be established; and for the two bulk implementation patterns the Commission confirms are possible, including the note that the ten second rule does not apply to the second one.
• Deutsche Bank, flow briefing, Verification of Payee go-live, 9 April 2026. Downloaded and read directly. Source for the measured opt in and opt out rates on files submitted to Deutsche Bank over EBICS between October 2025 and January 2026, for the observation that the German EBICS approach currently lets a corporate authorise or reject an entire payment file with no partial automatic execution, for the absence of a customer to bank standard, and for the point that the scheme rulebook defines only a minimum set of matching rules so outcomes depend on each provider algorithm, with legal form abbreviations a common cause of a no match.
• Banking.Vision, VoP opt-out for SEPA files: BaFin grants transitional relief for EBICS customers, 20 August 2025. Practitioner commentary from a payments consultancy, cited for the German market point that files carrying a single transfer order could not be opted out, and that BaFin has said in its own questions and answers that it will not object to a waiver for such files until further notice. Used as corroboration and market context, not as the basis for any statement about the Regulation.
• Rivane IBAN checker. The format check referred to in this article, published on this site. The measurements quoted were produced by running its own published logic, which applies the ISO 13616 registry length for the country and the ISO 7064 mod 97 check digit test.

A note on how this was researched. Every statement about what Verification of Payee requires comes from the text of Article 5c of Regulation (EU) 2024/886, opened on EUR-Lex and read directly rather than through a fetched summary. That covers the service and its timing, the identifier based matching route for a payee that is a legal person, the rule that a result cannot prevent authorisation, the package opt out and the right to opt back in, the warning and liability information duties, the allocation of liability, and the compliance dates. The two European Payments Council answers were read on the Council site in full, and the European Commission questions and answers document was downloaded and read at questions 117 to 120 rather than summarised. The Deutsche Bank flow briefing of 9 April 2026 was downloaded and read, and every figure attributed to it in this article appears in its own table of opt in and opt out rates for files submitted over EBICS. The Banking.Vision piece is practitioner commentary and is cited only for the German market point it makes about single order files, attributed as such. The measurements of what an IBAN check digit catches were produced by running the checker published on this site over 1,000,000 random corruptions per case, using published example IBANs rather than any real account. No public posts on X are cited here. Searches surfaced no credible public posts on this subject from a bank, a regulator or a named practitioner that could be verified on the rendered page, and account timelines and search on X sit behind a login the research browser did not have, so a clean citation was preferred to an unverified excerpt. The data model and the identifiers in it are a worked example of structure and describe no real organisation, supplier or account. Nothing here is legal advice, and the obligations that apply to any business come from the Regulation and from its agreements with its own providers rather than from this article.