Unsupported Characters in pain.001 Files
Bank networks and payment processors restrict which characters are allowed in pain.001 name and address fields. Accented letters, smart quotes, and special symbols cause silent rejections.
Why banks restrict character sets
The SWIFT network and many domestic payment rails were designed for ASCII or the SWIFT Basic Latin character set — a subset of ASCII without accented letters, special symbols, or Unicode characters beyond U+007E.
Even though XML is UTF-8 and your pain.001 file can contain any Unicode character, the bank's internal systems often cannot process them. The file may pass XSD validation perfectly while containing characters that get rejected downstream.
Allowed vs forbidden characters
Most bank profiles allow a specific character set. The SWIFT Basic Latin set (also called SWIFT Latin character set) is the most restrictive common denominator.
Character set reference for pain.001 text fields
ALLOWED (SWIFT Basic Latin):
A-Z a-z 0-9
/ - ? : ( ) . , ' +
Space Newline (in some fields)
PROBLEMATIC (accepted by XML, rejected by many banks):
é è ê ë (French accented)
ä ö ü ß (German umlauts)
à â (common European)
" " (smart/curly quotes — not standard ASCII " )
– — (en-dash, em-dash — not standard ASCII -)
& < > (XML special — must be escaped as & < >)
ALWAYS FORBIDDEN:
Emoji, symbols (€ £ ¥ © ®), CJK charactersThe most common culprits
German and French company names are the most frequent source: 'Müller GmbH', 'Société Générale', 'Hôtel des Alpes'. These look perfectly normal in a business context but contain characters outside the SWIFT Basic Latin set.
Smart quotes appear when name or address data is copy-pasted from Word documents or PDF exports. The character looks identical to a standard apostrophe or double quote but has a different Unicode code point.
En-dash (–) and em-dash (—) appear when hyphenated names or address ranges are pasted from formatted documents. They look like hyphens but are rejected by SWIFT-based networks.
Before and after character normalization
<!-- REJECTED: contains ü and ß -->
<Nm>Müller & Söhne GmbH</Nm>
<AdrLine>Straße 12</AdrLine>
<!-- ACCEPTED: transliterated to SWIFT Basic Latin -->
<Nm>Mueller + Soehne GmbH</Nm>
<AdrLine>Strasse 12</AdrLine>Which fields enforce strict character sets
Name fields (Nm under Dbtr, Cdtr, DbtrAgt, CdtrAgt) are the most commonly restricted. The name is displayed on the recipient's bank statement and must be processable by all systems in the payment chain.
Address fields (AdrLine, TwnNm, Ctry) are also restricted in most profiles. Remittance information (Ustrd — unstructured remittance) is sometimes more permissive, but not universally.
The CH.03 Swiss Payment Standards profile explicitly references the SWIFT Latin Character Set for name and address fields. Violations cause a specific rejection code: FF01 (Invalid file format).
How to handle restricted characters
The standard approach is transliteration: replace accented characters with their ASCII equivalents before generating the file. ü → ue, ä → ae, ö → oe, ß → ss, é → e, ç → c. This is lossy but accepted practice in payment processing.
Remove or replace smart quotes, dashes, and special symbols at data ingestion time — not at serialization time. Catching these at the source prevents them from reaching the payment file.