All articles

Swiss banking · Swiss banking, file by file, Part 2

pain.001 explained: Swiss payment files for suppliers

Published 2026-11-06 · 11 min read

What is pain.001?

pain.001 is the ISO 20022 message "Customer Credit Transfer Initiation": the file a business sends its bank to order one or many credit transfers. It carries the account to debit, the requested execution date and, per payment, the amount, the creditor, the account and a reference. The bank executes the payments, and they come back later on your statement, as camt.053.

In Switzerland and Liechtenstein, the SIX Swiss Payment Standards define what a pain.001 must look like. From 14.11.2026 the Implementation Guidelines for pain.001, SPS 2026 version 2.3 apply. They come with their own XML schema, pain.001.001.09.ch.03.xsd. Banks reject a file that violates the schema. That is why the guidelines tell software providers to test every file against it first (section 3.6).

For a domestic payment (payment type D): payment method TRF, currency CHF or EUR, and with a Swiss or Liechtenstein IBAN the creditor’s bank may be left out, because the IBAN identifies it. EUR stays in this payment type until November 2027. What TILL does for Swiss books in general is on the Swiss page.

How does an open bill become a pain.001 file?

An open vendor bill becomes a pain.001 file in five steps. Once the bank has paid, one line on the statement closes the bill again. The table shows the whole way, with the commands TILL has for it. Each command is also an MCP tool an agent can call.

Step 5 is the one that matters: generate_pain001 always answers transmitted: false. If the debit account has an EBICS channel, the reason says upload_in_ebanking, otherwise no_channel. TILL’s EBICS client only downloads statements and signs nothing, as part 1 of this series, on EBICS explains. In the public beta the module that connects to the bank is not published yet: you import the camt.053 from e-banking (step 7). When a connected agent calls one of the writing commands (steps 2 to 5, 7 and 8), the call becomes a proposal by default, which a person approves.

What is inside a pain.001.001.09 file?

A pain.001.001.09 file has three levels. The A level (GrpHdr) describes the whole file, the B level (PmtInf) one debit account with one execution date, the C level (CdtTrfTxInf) a single payment. This is a file with two payments, as TILL writes it:

<?xml version="1.0" encoding="UTF-8"?>
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.001.001.09">
 <CstmrCdtTrfInitn>
  <!-- A level: the whole file -->
  <GrpHdr>
   <!-- new for every file; the bank checks for duplicates -->
   <MsgId>M4h1x8q2c7v0n5b3k9r6t2w8y</MsgId>
   <CreDtTm>2026-11-06T08:15:00.000Z</CreDtTm>
   <NbOfTxs>2</NbOfTxs>
   <!-- 1250.00 + 320.50 -->
   <CtrlSum>1570.50</CtrlSum>
   <InitgPty><Nm>Muster Werkstatt GmbH</Nm></InitgPty>
  </GrpHdr>
  <!-- B level: one debit account, one date -->
  <PmtInf>
   <PmtInfId>P4h1x8q2c7v0n5b3k9r6t2w8y</PmtInfId>
   <PmtMtd>TRF</PmtMtd>
   <!-- one batch booking for the whole run -->
   <BtchBookg>true</BtchBookg>
   <NbOfTxs>2</NbOfTxs>
   <CtrlSum>1570.50</CtrlSum>
   <ReqdExctnDt><Dt>2026-11-10</Dt></ReqdExctnDt>
   <Dbtr><Nm>Muster Werkstatt GmbH</Nm></Dbtr>
   <DbtrAcct><Id><IBAN>CH7280005000088877766</IBAN></Id></DbtrAcct>
   <!-- clearing number, derived from the IBAN -->
   <DbtrAgt><FinInstnId><ClrSysMmbId>
    <ClrSysId><Cd>CHBCC</Cd></ClrSysId><MmbId>80005</MmbId>
   </ClrSysMmbId></FinInstnId></DbtrAgt>
   <ChrgBr>SLEV</ChrgBr>
   <!-- C level: one payment, one bill -->
   <CdtTrfTxInf>
    <PmtId>
     <InstrId>I7m2p9s4d1f6g3j8l5z0a2c4e</InstrId>
     <EndToEndId>E7m2p9s4d1f6g3j8l5z0a2c4e</EndToEndId>
    </PmtId>
    <Amt><InstdAmt Ccy="CHF">1250.00</InstdAmt></Amt>
    <Cdtr><Nm>Papeterie Muster AG</Nm></Cdtr>
    <!-- a QR-IBAN, so a QR reference is required -->
    <CdtrAcct><Id><IBAN>CH4431999123000889012</IBAN></Id></CdtrAcct>
    <RmtInf><Strd><CdtrRefInf>
     <Tp><CdOrPrtry><Prtry>QRR</Prtry></CdOrPrtry></Tp>
     <Ref>210000000003139471430009017</Ref>
    </CdtrRefInf></Strd></RmtInf>
   </CdtTrfTxInf>
   <CdtTrfTxInf>
    <PmtId>
     <InstrId>I2q8w5e1r7t3y9u4i0o6p2a8s</InstrId>
     <EndToEndId>E2q8w5e1r7t3y9u4i0o6p2a8s</EndToEndId>
    </PmtId>
    <Amt><InstdAmt Ccy="CHF">320.50</InstdAmt></Amt>
    <Cdtr><Nm>Holzbau Beispiel GmbH</Nm></Cdtr>
    <!-- a plain IBAN with a SCOR reference -->
    <CdtrAcct><Id><IBAN>CH4821966000009613388</IBAN></Id></CdtrAcct>
    <RmtInf><Strd><CdtrRefInf>
     <Tp><CdOrPrtry><Cd>SCOR</Cd></CdOrPrtry></Tp>
     <Ref>RF18539007547034</Ref>
    </CdtrRefInf></Strd></RmtInf>
   </CdtTrfTxInf>
  </PmtInf>
 </CstmrCdtTrfInitn>
</Document>

TILL mints the four references MsgId, PmtInfId, InstrId and EndToEndId once, when the payment run is drafted, and stores them. Each fits 35 characters and the character set SIX allows for references. So a file generated again is the same file, byte for byte. Upload it twice by mistake and it carries the same MsgId, which lets your bank catch the duplicate. A run that is already paid is not generated again at all (already_paid).

What does a structured address look like in pain.001?

A structured address in pain.001 sits under PstlAdr, with street, building number, post code, town and country each in its own element. From 14.11.2026, SIX says, the addresses of all parties to a payment must be built this way and carry at least town and country as separate data elements. For the creditor of the first payment above it would look like this:

<Cdtr>
 <Nm>Papeterie Muster AG</Nm>
 <PstlAdr>
  <!-- recommended -->
  <StrtNm>Bahnhofstrasse</StrtNm>
  <BldgNb>12</BldgNb>
  <PstCd>8999</PstCd>
  <!-- always, whenever an address is given -->
  <TwnNm>Seldwyla</TwnNm>
  <Ctry>CH</Ctry>
 </PstlAdr>
</Cdtr>

Besides the structured address there is the hybrid one: town and country as above, plus at most two AdrLine lines of 70 characters each for whatever fits no field. What is already in a field must not turn up again in those lines. Whether your bank accepts the hybrid address depends on what it offers. The fully unstructured address, lines only with no town and country, is no longer allowed under the Swiss Payment Standards from 14.11.2026.

From the SIX documents: the new address format is mandatory for all payment orders from 14.11.2026, and your software must hold the creditor’s address and pass it on in the correct form. Incomplete addresses can get a payment rejected. Your own address as the debtor, on the other hand, is added by the bank from its master data; you do not have to send it. As an element, the guidelines list the creditor address as optional, but they require town and country as soon as an address is given.

What changes on 14 November 2026?

On 14 November 2026 the parallel phase of the ISO 20022 versions ends in Switzerland, and the structured address becomes mandatory. In summer 2026 Swift and the EPC suspended their own November deadline for addresses; Switzerland keeps its date. As of 28.10.2026 the sources say:

The Swift suspension concerns payments over the Swift network, not the Swiss rules. SIX says the guidelines valid from 14.11.2026 stay unchanged and in force. The SIC release of 13.11.2026 ships with an adjusted scope: SIC waives the address validation so that forwarding into and out of the Swift network does not stall. That is why payments with unstructured addresses may still arrive. Your own file still needs the new layout.

How does the payment come back into the books?

The payment comes back as a debit on your bank statement, and that line closes the bills. TILL looks for the matching run in two ways: by the EndToEndId of a single payment, or by the run’s PmtInfId, then with the run’s total. Which one your bank uses depends on BtchBookg and on its statement setting; TILL takes either.

When reference and amount agree, the bank inbox proposes the run as "sure". When you book the line, TILL marks the run paid: one payment per bill, debit 2000 accounts payable, credit the bank account, on the line’s booking date. When the line is neither the run total nor one of its payments, TILL refuses with amount_mismatch instead of guessing.

You can also mark a run paid without a bank line, with mark_batch_paid and confirmation: true, because that confirmation states a fact about the bank. Not twice, though: a paid run refuses every further confirmation.

What can TILL’s pain.001 not do?

TILL’s pain.001 is meant for payments to suppliers and nothing beyond. What it does not do today:

• It does not go to the bank by itself. In the public beta TILL uploads nothing, signs nothing and releases nothing. You upload the file in e-banking and release it there. In the public beta TILL does not read the bank’s pain.002 status report either: a rejected file shows up at your bank.
• It carries no creditor address yet, only the name and the IBAN. SIX makes the structured or hybrid address mandatory for all parties from November 2026 and expects software to pass on the creditor’s address; the guidelines list the element as optional, and incomplete addresses can be rejected. Ask your bank whether it executes a domestic payment without a creditor address from 14.11.2026 before you rely on it.
• Only CHF and EUR, one currency per run. Meant for creditors with a Swiss or Liechtenstein IBAN (payment type D). TILL does not refuse a foreign IBAN today, but such a payment is no longer domestic and carries no creditor agent. No SEPA payments, no foreign currencies, no instant payments, no salaries.
• A bill to a QR-IBAN without a valid QR reference is refused (needs_qrr_reference) rather than given an invented one. The same goes for a vendor with no name or no IBAN.
• The full check against pain.001.001.09.ch.03.xsd runs in TILL’s test suite, not on every generation. When it generates, TILL checks its own file for sums, counts, reference lengths, IBANs, check digits and the rule that a QR-IBAN needs a QR reference.

TILL is a public beta and open source under MIT. How an agent books over MCP without double-counting is shown in MCP meets the ledger, and what an agent may do in TILL is on the agents page.

Checklist: is your payment file ready for 14 November 2026?

These questions hold for any software that writes pain.001. Go through them with a real file before 14.11.2026:

1. Does the file’s namespace say pain.001.001.09?
2. Does every creditor have a name and, where an address is given, town (TwnNm) and country (Ctry) in separate fields?
3. Does your software hold each creditor’s address and write it into the file?
4. Are street, building number and post code in their own fields rather than together on one line (recommended)?
5. Is the MsgId new for every file, across 90 days too?
6. Does CtrlSum equal the sum of the amounts and NbOfTxs the number of payments?
7. Does a QR-IBAN only ever go out with a QR reference, and is free text at most 140 characters?
8. Have you checked the file against pain.001.001.09.ch.03.xsd before uploading it?
9. Have you replaced old e-banking templates and checked your standing orders against your bank’s instructions?
10. Does your bank accept the hybrid address, and does it execute a domestic payment without a creditor address?