Someone living in Spain gets paid into a euro account issued in Lithuania. Their gym wants a direct debit, the form rejects the IBAN, and the support agent explains that only Spanish accounts are accepted. Nothing about that payment is technically harder than a domestic one. The rails are identical, the settlement time is identical, and the cost to the collecting business is identical.
This is the practice the European Commission and national regulators call IBAN discrimination, and it survives mostly because refusing is cheaper for the firm doing it than fixing the system that refuses.
What the rules actually say
The EU regulation that created the single euro payments area contains a reachability principle. If a payment account can receive or send euro credit transfers and direct debits domestically, it has to be usable for the same payment types from anywhere in the area, and a business collecting money cannot require that the counterparty's account sits in a particular member state.
The practical scope matters. This applies to euro transfers and euro direct debits inside SEPA, which includes the EU plus a handful of associated countries. It does not create a right to be a customer of any firm, it does not apply to payments in other currencies, and it does not override anti-money-laundering obligations. Payments outside that scope run on different rails with different economics, which is the subject of SEPA versus SWIFT.
Why systems still refuse
Three reasons, and only one of them is deliberate. The first is old software. Billing platforms and payroll systems built before SEPA validate against a domestic account number format, and a foreign IBAN fails the pattern check before any human sees it. Nobody at the company decided to exclude anyone. The field simply predates the rule and no one has funded the rewrite.
The second is direct debit mandates. Collecting a direct debit from another country is operationally identical on paper, but internal fraud rules, mandate handling and return codes are often configured per country, and the safe default in a risk workshop is to switch the other countries off.
The third is risk appetite dressed as policy. Certain country codes carry a reputation because a large share of the IBANs issued there belong to payment institutions and electronic money institutions rather than banks. A firm that has been burned by fraud from pooled accounts writes a rule about the prefix instead of a rule about the underlying account type, because the prefix is the field it already has.
A country-code rule is a blunt instrument. It blocks a legitimate resident who happens to bank with a modern provider, and it does nothing to stop a determined bad actor who can obtain a domestic account. If the concern is account ownership, verify ownership. Do not filter on the first two letters.
The payment institution question is a different question
Brokers, prop firms and any business holding client money face a genuine problem that looks similar from the outside. They are required to know that funds came from the client and go back to the client. Historically some payment institution and e-money accounts returned thin sender details on incoming transfers, and a few operated pooled account structures where the IBAN belonged to the provider rather than the individual. A firm that credited such a payment could not evidence whose money it was.
That gap has narrowed as providers moved to accounts held in the customer's own name, and the mechanics are set out in how virtual IBANs work and in what an EMI licence permits. But the underlying obligation has not changed, so a firm refusing a payment because the sender name does not match the account holder is doing its job, and calling that IBAN discrimination is a category error.
The distinction is easy to test. If the refusal disappears when the account is in your own name with the same country prefix, it was a compliance rule. If the refusal survives a perfect name match and the only variable is the country code, it was not.
What to do as an individual
Ask for it in writing, with the reason. Support scripts blur the two cases together, and a written reason forces the firm to pick one. If the answer is that the account country is not supported for a euro SEPA payment, that is the reportable version, and it can be escalated first through the firm's own complaints process and then to the national authority responsible for enforcing SEPA rules in the country where the firm operates.
In the meantime, the practical workaround is to hold more than one account. Traders funding accounts across several venues already do this for currency reasons, since a multi-currency account removes the conversion leg, and having a second account with a domestic prefix removes the argument entirely. It is not a satisfying answer, but it takes an afternoon rather than six months.
What a firm should build instead
If you run a business that collects payments across Europe, the country-code filter is a liability with an expiry date. Regulators have publicly pushed on this, the reporting routes exist, and every refusal is a customer you turned away with a message that reads as arbitrary.
The replacement is a set of rules about things that actually carry risk: does the account holder name match the verified client, is the account in the client's own name rather than a third party's, is the payment consistent with what this client has done before, and is the provider itself an authorised institution. Those checks belong in the same system that holds the client record, so a mismatch raises a case with the file attached rather than an email chain. Firms running this at volume put the logic in the back office alongside the client ledger, which is also where the audit trail has to live when a regulator asks two years later.
And publish the policy. Half the anger in these tickets comes from discovering the rule at the moment of payment. A funding page that lists which account types are accepted, and why, converts a complaint into a decision the client makes before they start.
"If your reason for refusing an account is a country code, you do not have a risk policy. You have a validation rule that somebody wrote in 2009 and nobody has been paid to revisit since."
— Roman Onta, Executive Director, SINGUARD
Key Takeaways
- SEPA reachability rules mean a euro account anywhere in the area should work for euro transfers and direct debits, regardless of its country prefix.
- Most refusals come from legacy field validation and per-country direct debit configuration rather than a deliberate decision to exclude anyone.
- A firm refusing a payment because the sender name does not match the verified client is meeting an AML obligation, which is a separate issue from country filtering.
- Get the refusal reason in writing: it separates the reportable case from the compliance case and tells you which route to take next.
Frequently Asked Questions
Is it legal to refuse a foreign IBAN in the EU?
For euro payments inside the SEPA area, EU rules on SEPA reachability require that a payer or payee be able to use any euro payment account in the area. A business collecting a direct debit or paying a salary cannot insist that the account sits in one particular member state. Refusing an account purely for its country code is what the practice known as IBAN discrimination describes.
Why does a broker reject my Wise or Revolut IBAN?
That is usually a compliance decision rather than a country issue. Firms holding client money have to establish that the account belongs to the client, and some payment institution accounts historically returned limited or pooled account holder details on incoming transfers. The firm's policy on non-bank accounts, not the IBAN prefix, is what drives the refusal.
What can I do if a company refuses my IBAN?
Ask for the refusal in writing with the reason stated, since a compliance reason and a systems limitation call for different responses. If the payment is a euro transfer inside SEPA and the reason given is the country of the account, the matter can be raised with the company formally and then reported to the national authority responsible for enforcing SEPA rules in that member state.