ISO 20022 Compliance and Implementation Toolkit

Start with the governing source#

ISO 20022 message definitions and market-practice rules are separate layers. Choose the message your bank or clearing channel requires; do not assume the highest numbered schema is accepted by that channel.

Layer	Current source	What to record
Base message	ISO 20022 message catalogue and archive	Message identifier, XSD checksum, retrieval date
Cross-border	Swift Standards Releases and your MyStandards profile	CBPR+ release, usage guideline, channel profile
SEPA	EPC SCT rulebook and implementation guidelines	Rulebook version, effective date, SCT/SCT Inst/SDD scheme
Bank-specific	Your bank's implementation guide and onboarding response	Product, channel, cut-off, account entitlement, accepted variants

The living roadmap tracks dated changes. The 2026 briefing explains the structured or hybrid address transition, while the compatibility matrix states exactly which checks Pain001 performs.

Validate a representative file#

Use the browser validator and message builder for a same-origin, local demonstration, or install the CLI for repeatable pipeline gates:

pip install pain001==0.0.70
pain001 -t pain.001.001.09 -d payments.csv --scheme sepa-sct --dry-run

The example corpus supplies positive and negative cases. Every scenario links to its input, expected outcome, message edition, scheme, and generated artefacts. Message specifications provide field-level XML schema documentation. The technical reference covers Python, CLI, REST, validation errors, and operational exit codes.

Implementation checklist#

Checkbox Name the target scheme, channel, bank product, message identifier, and implementation-guide version.
Checkbox Preserve source-data provenance and use masked test data outside production.
Checkbox Validate required fields, identifiers, exact decimal amounts, control totals, character sets, scheme rules, and the official XSD.
Checkbox Test positive, boundary, and intentionally invalid examples against the bank's certification environment.
Checkbox Record the tool version, command, configuration, XSD checksum, input checksum, output checksum, timestamp, and validation result.
Checkbox Keep the bank acknowledgement and map any rejection through the pain.002 reason-code reference.
Checkbox Obtain business, operations, security, and compliance sign-off before production enablement.
Checkbox Re-run the suite when an ISO, scheme, bank profile, or software version changes.

This checklist is a reusable control template, not legal advice and not proof that a receiving bank will accept a file. Pain001 can prove schema and shipped rulebook checks; only the bank can prove its profile, channel, and entitlement.

Migration and integration paths#

Starting point	Guide	Validation target
SWIFT MT101	MT101 migration and loader reference	pain.001.001.09 plus chosen market practice
Excel	Excel migration and loader reference	typed records before XML generation
CSV, JSON, SQLite, Parquet	Payment pipelines	the same shared validation pipeline
Application API	REST and Python reference	synchronous validation or asynchronous job result
AI workflow	MCP tools	local, read-only generation and validation tools
Editor workflow	LSP integration	diagnostics and completion before runtime

Run load and latency tests with production-shaped, non-sensitive batches. The website does not publish a universal throughput claim: hardware, schema, format, plugin, and validation profile all affect results. Treat non-zero CLI exit codes, structured REST errors, and pain.002 responses as operational events with owners and retry rules.

Audit evidence package#

For each controlled run, retain a manifest similar to this:

{
  "tool": "pain001",
  "tool_version": "0.0.70",
  "message": "pain.001.001.09",
  "scheme": "sepa-sct",
  "input_sha256": "<sha256>",
  "output_sha256": "<sha256>",
  "xsd_sha256": "<sha256>",
  "validation": "passed",
  "bank_profile": "not-evaluated",
  "executed_at": "<RFC3339 timestamp>"
}

Store that manifest with change approval, test evidence, bank certification, and the eventual acknowledgement. The Trust Centre links the site SBOM, security policy, accessibility statement, and architecture evidence.

Find help and contribute evidence#

Use GitHub Discussions for implementation questions, the issue tracker for website defects, and contact for direct feedback. Case-study and adopter-story submissions are welcome through a new issue; remove all real payment data first. Watch GitHub releases or the RSS feed for updates. Each documentation page can be saved locally with its Save page control; bookmarks remain on the device.