SWIFT pain.001 vs SEPA pain.001: What’s Actually Different?
pain.001 identifies a customer credit-transfer initiation message, but that shared name does not make every pain.001 file interchangeable. The selected payment scheme and bank profile determine the namespace, account identifier shape, charge bearer, payment-type fields, and additional validation. A file that is structurally sensible for one route can be wrong for another.
The implementation does not use one global “SWIFT version”
In the current profiles, ING and BBVA use pain.001.001.03; Citi falls back to the credit-transfer default of pain.001.001.03. Deutsche Bank is the configured pain.001.001.09 profile. Standard Chartered Straight2Bank is also configured as pain.001.001.03, despite being a SWIFT TT/RFT profile.
.09 setting from the broader CBPR+ migration discussion. The converter uses the version configured for the chosen profile. For that migration context, see MT101 to pain.001.
What differs in the implemented profiles
| Area | SEPA profile examples | SWIFT Straight2Bank example |
|---|---|---|
| Payment type | The generator writes SvcLvl/Cd = SEPA for a SEPA credit transfer. | TT writes URGP plus IN; RFT writes proprietary local instrument TPBT. |
| Account identifier | The shared SEPA input schema validates an IBAN format and checksum. | The SWIFT input path accepts a non-empty account number or IBAN. If it is not an IBAN, the generator writes it as Othr/Id with BBAN. |
| BIC | Deutsche Bank requires the debtor-agent BIC but has no profile-specific BIC length rule. Its .09 output uses BICFI. | The shared SWIFT schema requires a creditor BIC. Straight2Bank additionally requires exactly 11 characters for recipient and intermediary agent BICs. |
| Charge bearer | The generator writes fixed SLEV. | For Straight2Bank, missing ChrgBr or SLEV becomes SHAR; explicit CRED, DEBT, and SHAR are preserved. |
| Address handling | Deutsche Bank requires recipient town and country in dedicated fields. Generic profiles write structured town/country when supplied; ING limits unstructured address output to two lines. | Straight2Bank formats supplied creditor address data as English Set1 output: up to three word-wrapped 35-character lines, plus country. |
| Character validation | ING restricts names/remittance to Latin-1; Citi restricts its end-to-end reference to its own legacy set; BBVA has no profile-specific character rule encoded. | Straight2Bank checks multiple free-text fields against a narrower set: letters, digits, / - ? : ( ) . , ', and space. |
Address fields are profile rules, not a universal split
The same XML address container can be populated differently. Deutsche Bank validates recipient city and country before generation and writes TwnNm/Ctry. Straight2Bank applies its own line-wrapping routine when creditor address data is supplied. A generic SEPA path can use structured town/country when both are available, with an unstructured fallback when they are not. Map city, country, street, and postcode independently so the selected profile can construct the required shape.
How the converter chooses the path
- Select the payment scheme. The generator writes the SEPA service level only for the SEPA path; the Straight2Bank profile writes TT or RFT payment-type fields on the SWIFT path.
- Select the bank profile. It provides the namespace and profile checks such as Deutsche Bank structured address requirements or Straight2Bank's agent-BIC and character rules.
- Map account and agent data to the selected route. An account number that is acceptable as a SWIFT
BBANis not a substitute for an IBAN in the shared SEPA validation path. - Do not copy a charge-bearer or address block from a file generated for another scheme.
Need payment XML at scale?
Our Enterprise API handles bank-specific formatting automatically.
Explore the Enterprise APIReady to generate bank-compliant SEPA XML files?
Stop struggling with manual formatting. Generate compliant ISO 20022 XML files in seconds directly in your browser.
Start Converting Now (Free)