← All guides

The SEPA character set: which characters are allowed in pain.001 names and references

The exact letters, digits and punctuation SEPA payments can carry, why the set is so small, and how to clean names, addresses and references without losing meaning.

A SEPA payment is a traveller. Between your ERP and the beneficiary’s account it may pass through your bank, a clearing system, the receiving bank and several screening engines, built in different decades by different vendors. The one thing all of those systems agree on is a small, safe alphabet. The SEPA character set is that alphabet: the characters that scheme rules guarantee can travel the whole journey unchanged. Anything outside the set — an ampersand in a supplier’s name, a hash in an invoice number, an accented letter in a street — may be stripped, mangled or cause the payment, or the whole file, to be rejected at any hop. This guide lists exactly what is allowed, explains the fields it applies to, and shows how to clean real-world data without destroying the information your reconciliation depends on.

The allowed set, in full

Here is the complete SEPA character set used by the EPC schemes for names, addresses and remittance information. Lowercase letters a to z. Uppercase letters A to Z. Digits 0 to 9. And this short punctuation list: forward slash /, hyphen minus -, question mark ?, parentheses ( ), full stop ., comma ,, apostrophe ’ replaced in practice by the plain apostrophe ', plus sign +, and space. That is all. Notice what is missing, because the missing characters are the ones real data loves: no ampersand, no asterisk, no hash or pound sign, no percent, no underscore, no at sign, no colon as a general character, no accented letters like ü or é, no euro sign, no emoji. If a character is not on the list, assume it cannot travel, however harmless it looks on your screen.

Two practical footnotes. First, the apostrophe: the scheme documents describe the typographic apostrophe, while systems in practice exchange the plain ASCII apostrophe, and names like O’Brien travel constantly; keep the plain one and test with your bank if a name matters. Second, some fields have rules tighter than the general set — structured references and certain code fields restrict characters further — so passing the general set is necessary but not always sufficient for a specific element. Treat the set as the outer fence. Field-specific rules, such as the RF creditor reference format covered in our guide to structured remittance information, are inner fences inside it.

Why the set is so small

It is tempting to read the small set as bureaucratic caution. It is actually scar tissue. Payment infrastructure grew up on systems with limited character encodings, where an accented letter could be stored as a different byte by each system it passed through, arriving as a different character or as garbage. A name that mutates in transit is not a cosmetic problem: screening engines compare names against sanctions and fraud lists, and a mutated name defeats the comparison. The restricted set is the intersection that every system in the chain can store and transmit byte-for-byte identically. XML itself can carry any character on Earth — the file format is not the constraint. The constraint is the forty-year-old relay race the file must run, and the scheme chose certainty over expressiveness.

There is a second reason: meaning. Several forbidden characters are operators in some system or other — the asterisk and hash in legacy formats, the ampersand in XML itself, the slash at the start of structured reference conventions. Keeping them out of free text removes ambiguity about where data ends and instructions begin. When a reference starts with a defined pattern, systems can recognise it as structured; when names cannot contain markup characters, a whole class of injection problems disappears. The small set is, in other words, part of the security model, not just a legacy habit. Understanding that helps teams take it seriously instead of treating it as an arbitrary hoop.

Where the rule applies in a pain.001 file

The character set applies to the free-text parts of the message: party names (initiating party, debtor, creditor, ultimate parties), postal address lines and fields, the remittance information — unstructured text and the additional remittance information — and references such as the remitter reference in structured blocks. It does not apply to fields whose format is defined separately: IBANs, BICs, amounts, dates and codes follow their own grammars, which is why an IBAN can look nothing like a word and still be fine. The fields that fail in practice are names and references, because those are the fields humans type. Nobody hand-types a date into the wrong shape as creatively as they type a trading name like Smith & Sons (Est. 1987) #4 into a supplier record — that single real-world name breaks the rules three separate ways.

Cleaning data without losing meaning

The standard approach is transliteration: a fixed table that maps every common forbidden character to an allowed equivalent, applied consistently at export time. Accented letters lose their accents or expand the way the local language writes them without accents — ü to ue in German convention or plain u, é to e, ß to ss. The ampersand becomes the word and in the local language, or a plus, or is dropped when it is decorative. Hash and asterisk in references are usually dropped or replaced with a hyphen, because references must stay matchable against invoices. The key word is consistently: the same mapping, in the same place in the pipeline, every time, so that the name on the payment always equals the name your reconciliation expects. Ad-hoc fixes by whoever exports this month create three spellings of one supplier and a matching problem that lasts for years.

• Transliterate at export, not in master data: your CRM can keep the beautiful legal name; the payment file gets the travel-safe version.
• Publish the mapping table inside your team: one page that says exactly what happens to each special character, so nobody improvises.
• Watch the copy-paste sources: names imported from spreadsheets and emails bring accents, smart quotes and non-breaking spaces with them.
• Test your worst real names, not samples: the supplier with the ampersand, the customer with the apostrophe, the reference with the hash.
• Re-check after every ERP or bank change: character handling is exactly the kind of default that resets silently during upgrades.

Length is the quiet partner of the character rules. Names in SEPA payments are limited, commonly to 70 characters, and remittance information to 140 characters in unstructured form. A perfectly legal character set cannot save a name that gets truncated mid-word at 70 characters, and truncation can itself produce a misleading name. When you clean data, check lengths in the same pass: shorten names deliberately, keeping the distinguishing words, rather than letting a system cut them blindly. Our validator reports both problems side by side — characters outside the set and fields over their useful length — because in real files they arrive together, usually in the same long-suffering supplier record. Character problems are also a recurring entry in our roundup of why banks reject SEPA files.

Invisible traps: smart quotes, non-breaking spaces and friends

The cruellest character failures are the ones you cannot see. Modern office software quietly replaces plain characters with prettier relatives: the straight apostrophe becomes a curly one, three dots become a single ellipsis character, and a space typed after certain words may be a non-breaking space, a different character that merely looks like a space. Copied from a word processor or an email, a name can therefore contain characters that render identically to legal ones on your screen while being entirely different bytes in the file. Your eyes pass the name; the bank’s character check does not. This is why character debugging by staring is hopeless, and why the correct tool is a checker that reports the exact character and position: the finding “character U+2019 at position 12” ends an argument that “but it looks fine” would otherwise sustain for days. When a name fails and you cannot see why, suspect an invisible substitute first, retype the field plainly in the source system rather than pasting, and the ghost usually leaves.

Two more visible-enough traps round out the rogues’ gallery. The first is the separator habit: references and names assembled by joining fields with characters people chose for readability — invoice 1042 / March / Berlin — inherit the joining character’s legality. Slashes happen to be allowed; the hash, asterisk and at sign that other teams chose are not, so a company-wide habit of writing references as INV#1042 is a rejection generator built into house style. Change the house style once, centrally, and a thousand future files heal themselves. The second trap is case and transliteration drift in the opposite direction: a name uppercased by one system, title-cased by another, transliterated by a third, until the same supplier exists in your data as three different strings, each individually legal. The character set cannot save you from that; only a single, documented mapping applied in one place can. Character discipline is therefore really two disciplines — legality, which a validator enforces perfectly, and consistency, which only process enforces. You need both, and this guide’s checklist gives you the first so you can spend your attention on the second.

It is worth asking why, if the set is so restrictive, payment users do not rebel — and the honest answer is that the restriction buys something they value more than punctuation: certainty that the data they screen, match and archive is the data that was sent. Compliance teams are the quiet constituency for the character set. Their screening tools compare names against watchlists under time pressure, across alphabets, and every exotic character is a chance for two systems to disagree about whether two strings are the same name. A payment stopped for manual review because a name mutated in transit costs more than a payment whose name was transliterated at export by a boring, documented rule. When you present the character set to colleagues, present it that way — not as the bank being fussy about symbols, but as the price of a name meaning the same thing in forty-one countries’ worth of systems. People accept restrictions they understand the purpose of, and this one’s purpose is that a name is a name everywhere it lands.

One practical note on testing: do not test your transliteration with your tamest data. Build a test batch from the ten ugliest real records you own — the longest name, the one with the ampersand, the reference with the hash, the address with three accented letters — and keep that batch as a regression test for every system change. Ordinary samples pass everywhere; the ugly ten are your canaries, and they are the records your future rejections are currently hiding inside.

A final judgement call: what if the legal name itself contains a character the set forbids, and the beneficiary’s bank expects the legal name? In practice, banks and screening systems work with the scheme character set every day, and the standard transliteration of a name is understood everywhere as the same name. What causes trouble is not transliteration; it is inconsistency — paying the same supplier under three different spellings. Choose the travel-safe spelling once, use it for every payment, and keep a note of the mapping with the supplier record. Then let the machine check you: validate your file free and every name and reference in it is swept against the set in milliseconds. On the paid plans the same sweep runs across a whole batch — see pricing — which is how a quarter’s new suppliers get checked in one pass instead of one rejection at a time.