Direct Debits

The collection family: MT104 direct debits to and from pain.008 customer direct debit initiations, with the SEPA payment type, mandates and creditor identifiers.

Formats

Format	What it is	Versions accepted	Emitted by default
`mt104`	Direct debit and request for debit transfer	n/a	n/a
`pain.008`	Customer direct debit initiation	`.001.08`	`.001.08`

Pairs

From	To
`mt104`	`pain.008`
`pain.008`	`mt104`
`canonical`	`mt104`, `pain.008`

Direct debits never convert to or from credit transfers: mt101 → pain.008, mt104 → pain.001, pain.001 → mt104 and pain.008 → mt101 are 422 unsupported-conversion. The canonical source only accepts a direct-debit initiation; a credit-transfer document sent to to=pain.008 is also a 422.

How fields map

A direct debit normalizes to an initiation document whose batches have kind: "direct-debit". The roles are literal: the creditor is the party collecting the money (on the batch), and each debtor is a party being debited (on the instruction).

MT104 to pain.008.

:20: becomes the message id; :21R: the payment information id; :30: the requested collection date.
:23E: in sequence A carries the SEPA payment type as OTHR/<code> (see Conventions).
:21E: becomes the creditor scheme identifier (at batch level in sequence A, per transaction in sequence B).
:50A:/:50K: (the creditor) become the batch creditor and creditor account; :52a: the creditor agent. :50C:/:50L: (the instructing party) become the initiating party.
In each transaction: :21: becomes the end-to-end id, :21D: the instruction id, :21C: the mandate id, :32B: the amount, :57a: the debtor agent, :59a: the debtor and debtor account, :70: remittance.
:71A: becomes the charge bearer, read from the creditor's side (see Conventions).

pain.008 to MT104. One MT104 per PmtInf batch, because the collection date, the payment type and the creditor are message-level in MT104.

Where information is lost

Situation	Warning
Mandate signature date and amendment details (MT104 has no field)	`DROP_FIELD`
A sequence type, local instrument or service level outside the table below; any category purpose	`DROP_FIELD`
`SLEV` charge bearer (no MT code); `:71A:SHA` is written	`CODE_UNMAPPED_PROPRIETARY`
pain.008 creation time and initiating party (the first creditor's name is used)	`MISSING_REQUIRED_DEFAULTED`
No `:21R:`: a payment information id `<MsgId>-<n>` is generated	`MISSING_REQUIRED_DEFAULTED`
MT104 sequence C totals (`:19:`, settlement `:32B:`) that disagree with the transactions	`AMOUNT_MISMATCH`
`:26T:`, `:72:`, transaction charges `:71F:`/`:71G:`	`DROP_FIELD`
A structured creditor address flattened into `:50K:`	`TRUNC_ADDRESS`
An MT104 over the 2,000-character message budget (written whole, never split)	`mt.page_overflow`

Conventions

SEPA payment type in :23E:. MT104 has no element for the SEPA payment type, so transmute carries it in sequence-A :23E: lines as OTHR/<code>. This is a transmute convention for bilateral use, not a network-defined code word:

:23E: Canonical pain.008
OTHR/FRST, OTHR/RCUR, OTHR/FNAL, OTHR/OOFF sequenceType PmtTpInf/SeqTp
OTHR/CORE, OTHR/B2B, OTHR/COR1 localInstrument PmtTpInf/LclInstrm/Cd
OTHR/SEPA serviceLevel PmtTpInf/SvcLvl/Cd

Any other sequence-A :23E: value is reported with DROP_FIELD, never guessed at.
No mandate signature date from MT104. A pain.008 built from an MT104 has no DtOfSgntr. SEPA schemes require one, so supply it yourself or treat the result as non-SEPA. /v1/validate with level=sepa reports the missing date.
Split batches share :20:. A pain.008 with several batches becomes several MT104 messages, one per batch, each with the same :20: (the message id) and its own :21R: (the batch id). Going the other way, a file of several MT104 messages becomes one pain.008 with each message's batches in input order; a later message's different :20: is reported with DROP_FIELD.
Charge bearer from the creditor's side. In MT104 the instructing customer is the creditor, so :71A: reads the other way round from MT103: BEN ↔ DEBT, OUR ↔ CRED, SHA ↔ SHAR.
Totals are checked, never written. Sequence C totals in an MT104 are compared with the transactions; pain.008 output never carries a control sum, and MT104 output never carries sequence C, because either would be a computed money total.

`:23E:`	Canonical	pain.008
`OTHR/FRST`, `OTHR/RCUR`, `OTHR/FNAL`, `OTHR/OOFF`	`sequenceType`	`PmtTpInf/SeqTp`
`OTHR/CORE`, `OTHR/B2B`, `OTHR/COR1`	`localInstrument`	`PmtTpInf/LclInstrm/Cd`
`OTHR/SEPA`	`serviceLevel`	`PmtTpInf/SvcLvl/Cd`

Example

curl -sS -X POST "https://api.transmute.403fin.io/v1/convert?to=pain.008" \
  -H "Authorization: Bearer $TRANSMUTE_KEY" \
  -H "Content-Type: text/plain" \
  --data-binary @- <<'MT'
:20:DD-2026-0001
:21R:DD-BATCH-1
:23E:OTHR/SEPA
:23E:OTHR/CORE
:23E:OTHR/FRST
:21E:CI-TEST-0001
:30:260620
:50K:/GB29NWBK60161331926819
ACME SUBSCRIPTIONS LTD
:52A:BBBBDEFF
:71A:SHA
:21:E2E-DD-1
:21C:MANDATE-0001
:32B:EUR49,90
:57A:AAAADEFF
:59:/DE89370400440532013000
JANE EXAMPLE
MT

The result document, formatted:

<PmtInf>
  <PmtInfId>DD-BATCH-1</PmtInfId>
  <PmtMtd>DD</PmtMtd>
  <PmtTpInf><SvcLvl><Cd>SEPA</Cd></SvcLvl><LclInstrm><Cd>CORE</Cd></LclInstrm><SeqTp>FRST</SeqTp></PmtTpInf>
  <ReqdColltnDt>2026-06-20</ReqdColltnDt>
  <Cdtr><Nm>ACME SUBSCRIPTIONS LTD</Nm></Cdtr>
  <CdtrAcct><Id><IBAN>GB29NWBK60161331926819</IBAN></Id></CdtrAcct>
  <CdtrAgt><FinInstnId><BICFI>BBBBDEFF</BICFI></FinInstnId></CdtrAgt>
  <ChrgBr>SHAR</ChrgBr>
  <CdtrSchmeId>...<Id>CI-TEST-0001</Id>...</CdtrSchmeId>
  <DrctDbtTxInf>
    <PmtId><EndToEndId>E2E-DD-1</EndToEndId></PmtId>
    <InstdAmt Ccy="EUR">49.90</InstdAmt>
    <DrctDbtTx><MndtRltdInf><MndtId>MANDATE-0001</MndtId></MndtRltdInf></DrctDbtTx>
    <DbtrAgt><FinInstnId><BICFI>AAAADEFF</BICFI></FinInstnId></DbtrAgt>
    <Dbtr><Nm>JANE EXAMPLE</Nm></Dbtr>
    <DbtrAcct><Id><IBAN>DE89370400440532013000</IBAN></Id></DbtrAcct>
  </DrctDbtTxInf>
</PmtInf>

The warnings are two MISSING_REQUIRED_DEFAULTED (info) entries, for GrpHdr/CreDtTm and GrpHdr/InitgPty; meta.targetType is pain.008.001.08.

Was this page helpful?