An indirect bank sends a SEPA credit-transfer batch through its sponsor, with separate file controls, CSM clearing, sponsor-account settlement and transaction-level exceptions.
Asha Traders (payer) → Bank Alba (indirect participant) · pain.001
The customer sends Bank Alba a file of euro credit transfers. This customer-to-bank file is separate from the interbank file Bank Alba later sends through its sponsor.
Step 1 of 10: Asha Traders submits a supplier batch
It authenticates the customer, checks the file count and control sum, validates individual transactions, screens them, and confirms funds before accepting the batch.
Screening checkpoint: Customer and transaction screening — Accepted items are screened before the sponsored interbank file is created.
This teaching batch contains five accepted payments totalling EUR 42,500.00. A real bank may reserve first and post after sponsor acceptance, depending on its product and ledger design.
The sponsor checks the technical envelope, file totals, duplicate identifiers, cut-off, participant authority and CSM reachability before using its own direct connection and settlement account.
Accepted transactions enter the cycle. The CSM calculates the direct participants' positions; Bank Alba's economic activity is represented inside its sponsor's position.
The indirect participant is visible in business and reconciliation data, but the sponsor owns the direct CSM position in this simplified arrangement.
Value moves between direct participants' settlement accounts. Sponsor Bank then records Bank Alba's share under their bilateral funding and accounting arrangement.
Nordbank reconciles the file control data, validates each transaction and posts the individual beneficiary credits. File acceptance does not remove transaction-level controls.
What this simplifies: The sponsor owns one direct connection and settlement account. Input credit file is explicitly a local interface label around pacs.008 transactions, not a universal SEPA message name.
EVIDENCE AT ARM'S REACH
These resources cover the message conversations explicitly authored in this flow. Scheme-neutral teaching files still require validation against the profile used in production.
An XSD checks XML structure. A usage guideline adds profile rules, conditional fields, code restrictions, and business controls. XSD-valid does not mean scheme-compliant.
Choose the exact message definition in the official catalogue. The base XSD checks XML structure; it does not prove compliance with a scheme profile.
The network profile that restricts how ISO 20022 payment and reporting messages are used for cross-border traffic.
Adds the November 2026 validation and structured-address changes; implement against the final SR2026 usage guidelines.
Final usage guidelines are published through MyStandards; the public release page gives the implementation timeline.
Open version sourceThe common high-value ISO 20022 market-practice layer used as a starting point by T2, CHAPS, Fedwire, CHIPS, and other payment infrastructures.
Non-binding market practice for structured party data, cover payments, investigations, and the transition between MT and ISO 20022 reporting.
The current scheme obligations, datasets, time cycles, and exception rules for a SEPA Credit Transfer.
The EPC profile describing how the ISO 20022 messages implement the SCT rulebook between payment service providers.
The current scheme rules for round-the-clock euro instant credit transfers and their exception handling.
Customer-to-PSP and Inter-PSP profiles for SCT Inst. EPC XSDs are technical validation subsets, not production artefacts or proof of full scheme compliance.
The controlling scheme rules for mandates, collections, R-transactions, timelines, and consumer refund rights.
Customer-to-PSP and Inter-PSP SDD Core profiles. EPC XSD technical validation subsets express guideline restrictions but are not production artefacts or proof of complete scheme compliance.
The business-to-business mandate, debtor-bank checking, collection, exception, and refund-right rules.
Customer-to-PSP, Inter-PSP, and e-mandate profiles. EPC XSD technical validation subsets express guideline restrictions but are not production artefacts or proof of complete scheme compliance.
The ECB release library for T2 RTGS and central-liquidity messaging, including public user specifications, business validation rules, and binding schemas.
The ECB release library for TIPS UDFS/UHB specifications, message examples, implementation guidance, and MyStandards message-version links.
Published TIPS scope-defining documents for the November 2026 release line.
Published for the November 2026 release process; confirm final approved artefacts before implementation.
Open version sourceThe Bank of England handbook for CHAPS message scope, enhanced data, returns, testing, and the MyStandards location of controlling schemas.
Fedwire message versions, usage guidelines, implementation guidance, testing material, and the controlled route to proprietary schemas.
The public CHIPS ISO 20022 resource hub, legal notes, rules, change summaries, and participant material access points.
A single fictional customer credit-transfer instruction. SYNTHETIC / TRAINING ONLY; illustrative unvalidated.
crc32:9703ecc6A fictional serial interbank customer credit transfer. SYNTHETIC / TRAINING ONLY; illustrative unvalidated.
crc32:f5e1bbacA fictional return of the pacs.008 sample after settlement — account closed (AC04), funds travelling back as a new settled movement. SYNTHETIC / TRAINING ONLY; illustrative unvalidated.
crc32:70b22f5bInitiation, customer and interbank status, payment, notification, intraday report, and statement.
crc32:705aa0afCustomer and FI cancellation, resolution, return, reversal, and structured investigation messages.
crc32:f4772381Field correspondence, transformation treatment, and data-loss notes for Cross-border customer credit transfer translation, in the spirit of public CBPR+ and PMPG translation guidance. Educational summary — the applicable usage guideline is the rule.
crc32:47a46ccbField correspondence, transformation treatment, and data-loss notes for Request-for-transfer to customer credit transfer initiation. Corporates migrating channel formats meet this mapping first.
crc32:52591871Field correspondence, transformation treatment, and data-loss notes for Legacy return-payment convention compared with the structured ISO 20022 payment return.
crc32:a221a68dCurated field requirements, contexts, operational meaning, and implementation cautions.
crc32:ce136c6aCurated field requirements, contexts, operational meaning, and implementation cautions.
crc32:febf784fCurated field requirements, contexts, operational meaning, and implementation cautions.
crc32:f5eb5043Positive and negative test cases across validation, rejection, return, recall, reversal, investigation, reconciliation, migration, instant payments, and screening.
crc32:98c48cc7A practical control list for semantic transformation and coexistence risk.
crc32:50787584Verified profile constraints with versioned evidence and explicit operating conditions.
crc32:ce355754Positive and negative lifecycle tests linked to verified profile rules.
crc32:52175ca5Discovery, controls, testing and operational-readiness checks for the profile.
crc32:dabcc15dOutcome-focused profile acceptance criteria with honest release gates.
crc32:90dc18baVersion, transformation, cutover and reconciliation controls.
crc32:90393a22Evidence that must be obtained from the owner before production readiness can be claimed.
crc32:581e94a5Verified profile constraints with versioned evidence and explicit operating conditions.
crc32:e3f04ae8Positive and negative lifecycle tests linked to verified profile rules.
crc32:3ea6d78cDiscovery, controls, testing and operational-readiness checks for the profile.
crc32:1fa713e1Outcome-focused profile acceptance criteria with honest release gates.
crc32:f5ef35bfVersion, transformation, cutover and reconciliation controls.
crc32:74567f42Evidence that must be obtained from the owner before production readiness can be claimed.
crc32:b86e4292Verified profile constraints with versioned evidence and explicit operating conditions.
crc32:c79b356dPositive and negative lifecycle tests linked to verified profile rules.
crc32:fb0221bcDiscovery, controls, testing and operational-readiness checks for the profile.
crc32:a574381cOutcome-focused profile acceptance criteria with honest release gates.
crc32:612a75adVersion, transformation, cutover and reconciliation controls.
crc32:d9f59c8dEvidence that must be obtained from the owner before production readiness can be claimed.
crc32:e565e272Verified profile constraints with versioned evidence and explicit operating conditions.
crc32:6f8b5902Positive and negative lifecycle tests linked to verified profile rules.
crc32:3b72999aDiscovery, controls, testing and operational-readiness checks for the profile.
crc32:d31e7e73Outcome-focused profile acceptance criteria with honest release gates.
crc32:0bf84f8fVersion, transformation, cutover and reconciliation controls.
crc32:e22fb314Evidence that must be obtained from the owner before production readiness can be claimed.
crc32:3955f552Verified profile constraints with versioned evidence and explicit operating conditions.
crc32:68dfa60cPositive and negative lifecycle tests linked to verified profile rules.
crc32:241f3e0fDiscovery, controls, testing and operational-readiness checks for the profile.
crc32:e68ff5f9Outcome-focused profile acceptance criteria with honest release gates.
crc32:fb5e2bd6Version, transformation, cutover and reconciliation controls.
crc32:58a94a4dEvidence that must be obtained from the owner before production readiness can be claimed.
crc32:12f561e3Generated mapping, field-matrix, test, checklist, acceptance-criteria, migration, manifest, checksum, and source-inventory bundle.
crc32:9d2559edGenerated mapping, field-matrix, test, checklist, acceptance-criteria, migration, manifest, checksum, and source-inventory bundle.
crc32:39e4ef6dGenerated mapping, field-matrix, test, checklist, acceptance-criteria, migration, manifest, checksum, and source-inventory bundle.
crc32:458732a2Generated mapping, field-matrix, test, checklist, acceptance-criteria, migration, manifest, checksum, and source-inventory bundle.
crc32:02c424d8Generated mapping, field-matrix, test, checklist, acceptance-criteria, migration, manifest, checksum, and source-inventory bundle.
crc32:4e9cc3dbGenerated mapping, field-matrix, test, checklist, acceptance-criteria, migration, manifest, checksum, and source-inventory bundle.
crc32:f40458b3Generated mapping, field-matrix, test, checklist, acceptance-criteria, migration, manifest, checksum, and source-inventory bundle.
crc32:8117003aGenerated mapping, field-matrix, test, checklist, acceptance-criteria, migration, manifest, checksum, and source-inventory bundle.
crc32:b811f27bGenerated mapping, field-matrix, test, checklist, acceptance-criteria, migration, manifest, checksum, and source-inventory bundle.
crc32:2a13b3532025 SEPA Credit Transfer rulebook ↗ — European Payments Council
Version 1.1 replaced version 1.0 at publication on 5 October 2025 and is stated to remain in effect up to 21 November 2027. It moves the date from which the unstructured address format is no longer permitted to 15 November 2026.
SEPA Credit Transfer Inter-PSP Implementation Guidelines ↗ — European Payments Council
Based on version 1.1 of the 2025 SCT rulebook. Companion Customer-to-PSP guidelines cover the pain.001 initiation leg.
A glossary of terms used in payments and settlement systems ↗ — CPSS (now CPMI), Bank for International Settlements
Terminology has evolved since this edition; newer CPMI publications refine some definitions.
Payments Signal editorial teaching models — Payments Signal
What this simplifies: One indirect participant, one sponsor and one CSM. Bilateral envelopes, cut-offs, settlement funding and status channels vary by sponsor service. Parties, files and amounts are fictional.
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.
Share an operational observation or ask a concrete payments question. Your name and message are public; your email remains private.
Loading the discussion…