pain.008 is the ISO 20022 CustomerDirectDebitInitiation message — the file a creditor sends to its bank to collect money from debtors' accounts by direct debit. It is the mirror image of pain.001: in pain.001 the payer pushes funds out, in pain.008 the payee pulls funds in, on the strength of a mandate the debtor has signed. In SEPA it carries both Core and B2B direct debit collections, and pain.008.001.02 is the version the SEPA implementation guidelines are built on.

What is the difference between pain.001 and pain.008?

Direction and authority. pain.001 is a credit transfer initiation — the account owner instructs their own bank to push money out, so no one else's permission is embedded in the message. pain.008 is a direct debit initiation — the creditor instructs its bank to pull money from someone else's account, so every transaction must carry the mandate data (mandate ID, date of signature, creditor identifier) that proves the debtor authorized the collection. Structurally they rhyme: group header, batch level, transaction level — but in pain.008 the batch belongs to the creditor and each transaction describes a debtor.

What are the SEPA direct debit sequence types FRST, RCUR, OOFF and FNAL?

They tell the banks where a collection sits in a mandate's life: FRST (first of a recurrent series), RCUR (subsequent recurrent), OOFF (one-off, single-use mandate), FNAL (final collection of a series). Since the November 2016 SDD Core rulebook change (version 9.0), FRST is no longer mandatory — a first collection may be sent as RCUR — and all sequence types can be presented up to one inter-bank business day before the due date (D-1), which removed the old five-day lead time for first collections.

Can a SEPA direct debit be refunded after collection?

Under the Core scheme, yes: the debtor can claim a no-questions-asked refund of an authorized collection for eight weeks after the debit, and up to thirteen months for an unauthorized one (no valid mandate). Under the B2B scheme there is no refund right for authorized collections — the trade-off being that the debtor's bank must verify the mandate with the debtor before paying. Creditors should treat Core collections as conditional cash until the refund window closes.

pain.008: SEPA Direct Debit Initiation Explained

pain.008 (CustomerDirectDebitInitiation) is the ISO 20022 message a creditor sends to pull funds — mandates, FRST/RCUR sequence types, Core vs B2B, refunds.

Reviewed by Tan Gravam Fact-checked Sep 1, 2026

pain.008 — CustomerDirectDebitInitiation — is the ISO 20022 message a creditor sends to its bank to pull money from debtors' accounts. It is the mirror image of pain.001: same family, same layered structure, opposite direction of authority. A credit transfer moves your own money out; a direct debit reaches into someone else's account — which is why the interesting parts of pain.008 are exactly the parts pain.001 doesn't have: the mandate data, the sequence types, and the refund rules that decide when collected cash is actually yours.

Where it sits

In SEPA, pain.008 is the customer-to-bank initiation message for both direct debit schemes — Core (consumer) and B2B — and pain.008.001.02 is the version the SEPA implementation guidelines are built on. A creditor batches collections into the file, the creditor's bank distributes them into the clearing, and the results come back as status reports and booked entries: pain.002 for rejects, camt.053/camt.054 for what actually hit the account.

The structure, and what's different from pain.001

The skeleton is family-standard — one group header, one or more payment information blocks, transactions inside them — but the roles flip:

The batch level belongs to the creditor. PmtInf carries the creditor's account, its bank, the requested collection date and the scheme (Core or B2B, in LclInstrm).
Each transaction describes a debtor (DrctDbtTxInf): who to debit, which bank, how much, and the remittance information that should let the debtor recognize the charge.
Every transaction carries mandate data. That is the structural heart of the message, and it has no pain.001 equivalent.

The mandate block is the message

A direct debit is only as valid as its mandate, and pain.008 makes the creditor restate it on every collection (MndtRltdInf):

Mandate ID — the reference of the signed mandate this collection executes.
Date of signature — when the debtor signed it.
Creditor identifier (CI) — the scheme-issued identifier of the collecting creditor, stable across banks, so a debtor can recognize and block a specific creditor rather than a specific account.
Amendment indicator and details — if anything about the mandate changed (creditor account, mandate ID, debtor account), the change travels inside the message.

The mandate data isn't metadata — it is the legal basis of the collection, restated transaction by transaction. Most direct debit rejects that aren't about money are about this block.

Sequence types — and the 2016 simplification

Each collection declares its place in the mandate's life: FRST (first of a recurrent series), RCUR (subsequent), OOFF (one-off), FNAL (final). Two things changed with the November 2016 Core rulebook (version 9.0) that older documentation still gets wrong:

D-1 for everything. Any collection — first, recurrent or one-off — can be presented up to one inter-bank business day before the due date. The old five-day lead time for first collections is gone.
FRST is optional. A first collection may be flagged plain RCUR; many creditors now never send FRST at all.

The debtor still has to know it's coming: the Core scheme requires pre-notification before the due date — by default 14 calendar days ahead, unless creditor and debtor have agreed a different timeline (an invoice stating the collection date counts).

Core vs B2B: the refund line

The two schemes share the message format; they differ in what the debtor can undo:

Core: the debtor can claim a no-questions-asked refund for eight weeks after an authorized debit, and up to thirteen months for an unauthorized one. Collected cash is conditional until that window closes — treat it that way in cash positioning.
B2B: no refund right for authorized collections. The counterweight is upfront: the debtor's bank must verify the mandate with its customer before honouring B2B collections, so a B2B mandate that isn't registered at the debtor bank is a guaranteed reject.

What goes wrong in practice

Mandate data drift. The mandate ID or signature date in the file stops matching what was actually signed — often after a system migration — and collections start rejecting on formalities.
Amendments not flagged. The creditor changes account or mandate reference and sends the next collection without the amendment block.
B2B without registration. The mandate exists on paper but was never confirmed at the debtor's bank.
Treating Core cash as final. Revenue recognized, position closed — then the eight-week refund arrives as a debit on the bank statement.
R-transaction blindness. Rejects, returns and refunds each come back through different channels at different times; if pain.002 and the statement feeds aren't reconciled per collection, the receivables ledger quietly diverges from the bank.