Pain001

Swift has deferred its structured-address deadline and will set a new date by December 2026. See what changed

ISO 20022 pre-flight validation

Deterministic ISO 20022 validation. Inside your perimeter.

Every pain.001 and pain.008 file checked against the official schema and the scheme rulebooks on infrastructure you control, before your bank sees it.

Book an architecture briefing Read the documentation

See a real run

Every finding names the rule it came from.

pain001 validate Network access denied

--scheme sepa-sct · 5 paymentsexit 0

  1. 01 ISO 20022 schema Passed
  2. 02 Scheme rulebook Passed
  3. 03 Bank profileYour bank’s guide
  4. 04 ChannelYour bank’s channel

Recorded from the pain001 CLI with all network access denied by the operating system. Nothing was uploaded.

Zero data egress. Validation makes no network calls, keeps no copy of your files and sends no telemetry.

pain.001 · pain.008 · SEPA · CBPR+ · CHAPS · Bacs · FPS · FedNow · ACH · MT101 migration

Try the browser sandbox

Pain001 by the numbers

Tested against the real world.1

Bank scenarios Each passing the official ISO 20022 XSD
42
Countries Covered by those scenarios
17
Message editions Specified field by field
12
Languages This site is translated into
34

What reviewers check first

Built for the review. Not the demo.

The questions a CIO, a CISO and a payments operations lead ask first, answered by how the software works.

Deterministic

The same input produces the same XML and the same findings on every run. Findings are structured data your controls can store beside the payment file.

Architecture

Air-gapped

Validation needs no network. The runs above were recorded with all network access denied. No payment data is uploaded and there is no telemetry.

Data handling

Auditable

Open source under Apache-2.0 or MIT, with signed releases, a published SBOM and build provenance. Your reviewers read the code, not a brochure.

Evidence for reviewers

The validation model

Four layers decide whether a bank accepts a file. Pain001 checks two, and says so.

  1. 01 ISO 20022 schema

    Checked. The official XSD for the message edition accepts the document, or it does not.

  2. 02 Scheme rulebook

    Checked. SEPA, CBPR+, CHAPS, Bacs, Faster Payments, FedNow, ACH and more, each finding named by its rule.

  3. 03 Bank profile

    Yours to confirm. Pain001 ships no bank profiles; your bank’s implementation guide still applies.

  4. 04 Channel

    Yours to confirm. Whether the file can be sent is decided by your bank, not by the file.

One deterministic pipeline

From the files you have. To the XML your bank expects.

Validate early, generate once, and keep the evidence beside the payment run.

  1. Step 1 of 3

    Load your data

    Read CSV, Excel, SQLite, JSON, Parquet, or SWIFT MT101 without rekeying it into another platform.

    Supported inputs

  2. Step 2 of 3

    Validate every layer

    Apply JSON Schema, identifier checks, scheme rulebooks, recomputed totals, and the official ISO 20022 XSD.

    Inspect the evidence
  3. pain.001.001.09.xml XSD valid
    <CdtTrfTxInf>
  <PmtId><EndToEndId>PaymentID6789</EndToEndId></PmtId>
  <Amt><InstdAmt Ccy="EUR">150.00</InstdAmt></Amt>
  <CdtrAgt><FinInstnId><BICFI>DEUTDEFFXXX</BICFI></FinInstnId></CdtrAgt>
  <Cdtr><Nm>Global Tech</Nm></Cdtr>
  <CdtrAcct><Id><IBAN>DE36210501700024690959</IBAN></Id></CdtrAcct>
  <RmtInf><Ustrd>Payment for Invoice-98765</Ustrd></RmtInf>
</CdtTrfTxInf>

    One credit transfer from a generated document, nesting collapsed for reading.

    Step 3 of 3

    Generate bank-ready XML

    Write a deterministic pain.001 or pain.008 document and retain machine-readable findings for review.

    Run it in your browser

The Pain001 suite

Five focused packages. One validation model.

Core

Pain001

Typed Python API, CLI, REST service, rulebooks, schemas, and deterministic XML generation.

Technical reference
check.py
import csv
from pain001 import validate_scheme

rows = list(csv.DictReader(open("payments.csv")))
result = validate_scheme(rows, profile="sepa-sct")
for v in result.violations:
    print(v.index, v.rule, v.message)

Output 1 SEPA-CDTR-IBAN creditor_account_IBAN must be a valid IBAN (ISO 13616 / mod-97)

AI agents

pain001-mcp

Seventeen local, read-only Model Context Protocol tools with human review kept in the loop.

MCP tools

Editors

pain001-lsp

Diagnostics and payment-rule feedback while a human is still editing the source data.

Editor support

Legacy migration

MT101 loader

Move SWIFT request-for-transfer workflows to pain.001.001.09 with explicit conversion findings.

MT101 migration

Treasury teams

Excel loader

Turn governed payment workbooks into validated records without copy-and-paste operations.

Excel loader

Evidence

Example corpus

Reproducible payment scenarios across schemes, countries, currencies, and message editions.

Browse the corpus

For engineering teams

Install, validate and generate. In a few explicit lines.

The CLI and Python API run the same checks. Exit codes are meaningful, findings identify their rule, and payment data stays on your machine.

Python 3.10+ · CLI · REST · MCP · LSP

Install Pain001
terminal

# Install the complete CLI

python -m pip install pain001

# Validate source data with a scheme rulebook

pain001 validate -d payments.csv \
  -t pain.001.001.09 \
  --scheme sepa-sct --explain

# Generate and pass the official XSD gate

pain001 generate -d payments.csv \
  -t pain.001.001.09 \
  -o out/

For regulated teams

Free at any scale. A named party with obligations when you need one.

The software stays Apache-2.0 or MIT, with no feature held back. Add a supported release line, private bank profiles derived under NDA, and integration recipes for your ERP or TMS.

Core line and branch coverage
100%
Website accessibility target
WCAG 2.2 AAA
Payment-data processing
Local only
Core licence
Apache-2.0 / MIT
Book an architecture briefing What is offered

Regulatory timeline

The cutover is done. Data quality is the next deadline.

Four dates a payments or risk committee is working to, and what Pain001 does about each one today.

  1. DORA applies across the EU

    ICT risk reviews now reach the software in the payment chain.

    SBOM, signed releases and build provenance, verifiable without asking us. Review evidence

  2. MT–MX coexistence ends on Swift

    Cross-border instructions travel as ISO 20022.

    pain.001.001.09 generated and checked against the official XSD. Message specifications

  3. Next By

    Swift sets the new structured-address date

    The rule against unstructured addresses, and the move from MT101 to pain.001 between banks, were deferred in August 2026.

    Structured and hybrid addresses, the CBPR-ADDR rule, and one-command MT101 conversion. 2026 briefing

  4. Through 2028

    Purpose codes, investigations, statements

    camt investigations and statement migration follow the payment messages.

    Tracked with primary sources in the living roadmap. ISO 20022 roadmap

Executive briefing

The deadlines are data deadlines

The ISO 20022 cutover is done: MT–MX coexistence on Swift ended on 22 November 2025, and more than 98% of payment instructions now travel as ISO 20022 (Swift). What remains is data quality. Swift deferred its November 2026 rule against fully unstructured postal addresses in CBPR+ payments and will set a new date by December 2026; the requirement itself stands.

Pain001 ships both requirements today: structured and hybrid address elements in generated XML, and one-command MT101 conversion to pain.001 version 9.

Book an architecture briefingRead the documentation