pacs008 logo pacs008

Trust Centre

This page is generated from the same registries the product is built from, so it cannot drift from what the software actually does. Everything below is verified as of 2026-07-28.

At a glance

Licence Apache-2.0
Current version 0.0.8
Ruleset version 2026.11.0
Ruleset hash sha256:97e373c7d4df2de7998df610dab1c0be2b93119a189f82246928b2698991f33a
Minimum Python 3.10 (tested on 3.10, 3.11, 3.12)
Source https://github.com/sebastienrousseau/pacs008
Package PyPI
Last verified 2026-07-28
Next review due 2026-08-28

Who maintains this

pacs008 is maintained by Sebastien Rousseau. It is an open-source project with a small maintainer base — at present, effectively one person.

We state that plainly because it is material to an adoption decision. A single maintainer means limited review redundancy and no guaranteed response time outside the published policy. If you are evaluating pacs008 for production payment workflows, weigh that alongside the licence and the validation limitations below, and consider pinning a known version.

What each interface can validate

Validation is layered. A result from one layer says nothing about the others, and no interface reports a layer it did not run.

Layer Python CLI REST Browser
Input Safety & Parsing (Layer 0) Stable Stable Stable Beta
Input Schema Validation (Layer 1) Stable Stable Stable Stable
Identifier & Format Verification (Layer 2) Stable Stable Stable Stable
XML Syntax & Namespace Validation (Layer 3) Stable Stable Stable Not implemented
XSD Sequence & Cardinality Checks (Layer 4) Stable Stable Stable Not implemented
ISO Semantic Consistency (Layer 5) Stable Stable Stable Not implemented
Scheme Profile Rules — CBPR+, CHAPS (Layer 6) Stable Stable Stable Beta
Effective-Date Rules — 14 Nov 2026 (Layer 7) Stable Stable Stable Beta
Organisation Policy Packs (Layer 8) Not implemented Not implemented Not implemented Not implemented

Published limitations

These are the layers the browser Workbench does not evaluate. It is marked beta for this reason.

Layer Browser status Why
Input Safety & Parsing (Layer 0) Beta CSV/JSON parsing present; no file-size or MIME enforcement implemented (no MAX_FILE_SIZE in static/js)
XML Syntax & Namespace Validation (Layer 3) Not implemented Browser generates XML but never parses it; no DOMParser usage in static/js
XSD Sequence & Cardinality Checks (Layer 4) Not implemented No XSD validation in static/js; the pacs.008 XSD URN appears only as a namespace string in generated output
ISO Semantic Consistency (Layer 5) Not implemented No control-sum, transaction-count or cross-field consistency checks in static/js
Scheme Profile Rules — CBPR+, CHAPS (Layer 6) Beta Postal address classified as fully structured / hybrid / unstructured, plus LEI format (ISO 17442); no wider profile rule set
Effective-Date Rules — 14 Nov 2026 (Layer 7) Beta The 2026 deadline is hardcoded in the address classifier; there is no selectable effective date
Organisation Policy Packs (Layer 8) Not implemented Not implemented in any interface

A passing result in the Workbench is not a statement about the layers above. For XSD and ISO-semantic checks, use the Python library, CLI or REST service.

Why the browser does not do XSD

Not a bundle-size or performance limitation. A WebAssembly validator measures 873 KB, comfortably inside the budget, and the site's Content-Security-Policy already permits 'wasm-unsafe-eval'.

The blocker is that browser-side XSD validation requires serving the ISO 20022 schema files from pacs008.com, which is redistribution of Registration Authority material whose terms have not been confirmed. The project stores derived rule logic and citations rather than reproducing source documents, and bundling schemas for public download is a stronger act than citing them.

Self-hosted deployments are unaffected: the Python library, CLI and REST service perform XSD validation against schemas you already hold locally. The full record is in DECISIONS.md (D-003).

Message coverage

Verified against the templates shipped in the package.

Family Name Versions Count
pacs.008 FI to FI Customer Credit Transfer pacs.008.001.01 - .13 13
pacs.002 FI to FI Payment Status Report pacs.002.001.12 1
pacs.003 FI to FI Customer Direct Debit pacs.003.001.09 1
pacs.004 Payment Return pacs.004.001.11 1
pacs.007 FI to FI Payment Reversal pacs.007.001.11 1
pacs.009 Financial Institution Credit Transfer pacs.009.001.10 1
pacs.010 Financial Institution Direct Debit pacs.010.001.05 1
pacs.028 FI to FI Payment Status Request pacs.028.001.05 1

Not implemented

We list these because their absence is easy to assume away.

Family Status Note
pain.* Not implemented No templates in the package. Relevant to the November 2026 MT101 CBPR+ retirement, which relays to pain.001. Scoped in sebastienrousseau/pacs008#13; out of scope is a legitimate outcome. Tracked
camt.* Not implemented No templates in the package. camt.110 becomes receive-and-consume mandatory in November 2026 and camt.110/111 both mandatory in November 2027. A known dated gap, not a current capability. Scoped in sebastienrousseau/pacs008#12. Tracked
head.001 Not implemented Business Application Header not shipped as a standalone template.

Scheme profiles

  • SWIFT CBPR+ (cbpr-plus) — stable, effective 2026-11-14
  • Bank of England CHAPS (chaps-uk) — stable, effective 2026-11-14
  • Eurosystem T2 RTGS (t2-rtgs) — stable, effective 2026-11-14
  • US Federal Reserve Fedwire (fedwire) — stable, effective 2025-03-10
  • HVPS+ High-Value Payments (hvps-plus) — stable, effective 2026-11-14
  • SEPA Instant Credit Transfer (sct-inst) — stable, effective 2025-01-01

Rule sources

Scheme rules are derived from published sources rather than reproduced from restricted material.

ID Publisher Document Effective Verified
SWIFT-ADDR-2026 S.W.I.F.T. SC SWIFT CBPR+ Removal of Unstructured Address Guidelines 2026-11-14 2026-07-28
BOE-CHAPS-2026 Bank of England Policy Statement — Mandating ISO 20022 Enhanced Data in CHAPS 2026-11-14 2026-07-28
ISO-20022-PACS008-13 ISO 20022 Registration Authority Financial Innovation & Transfer — pacs.008.001.13 Message Definition 2025-01-01 2026-07-28

Security and release integrity

  • Vulnerability disclosuresecurity.txt. Report privately; do not open a public issue.
  • Software bill of materialsCycloneDX SBOM, generated each build.
  • LicenceApache-2.0. The Apache Software Foundation publishes the licence in English only and does not recognise translations, so the English text is the only legally binding version.
  • Security architecture — see Security.

Data handling

The browser Workbench processes data locally in the page. Payment payloads are not sent to pacs008.com, not retained, and not included in analytics — there are no analytics. Every script is served from pacs008.com itself, and the Content-Security-Policy restricts script-src and connect-src to 'self'. See Privacy.

You remain responsible for following your own organisation's data-handling policy. Prefer synthetic data when evaluating.

What this project is not

  • Not a bank, and not affiliated with SWIFT, the Bank of England, or any scheme operator.
  • Does not transmit, route, or settle payments.
  • Scheme names are used descriptively to identify the rules implemented.
  • A passing validation result does not guarantee acceptance by any counterparty or production system. Validate against your own contractual and scheme obligations.