For banks

Everything your review needs, without a sales call

Free, open source and run entirely on your own infrastructure. The evidence your risk, security and procurement teams ask for, in one download.

Verify this site’s release yourselfNo account, no NDA
  1. Fetch the release and its checksums

    gh release download -p '*' \
      -R sebastienrousseau/pain001.github.io
  2. Check every file against SHA256SUMS

    shasum -a 256 -c SHA256SUMS

    OK for every file

  3. Verify the build provenance (Sigstore)

    gh attestation verify pain001-site-*.tar.gz \
      -R sebastienrousseau/pain001.github.io

    Exit 0

Commands and results checked against the published release. The CycloneDX SBOM is also served at /sbom.cdx.json.

Evidence a reviewer can check without asking us

Every claim below resolves to an artefact you can fetch yourself. None of it requires a call, an NDA, or our word for it.

  • Bill of materials sbom.cdx.json

    CycloneDX, generated at build time and published with every deploy.

  • Release integrity Signed tags & checksums

    Every release tag is SSH-signed and ships SHA256SUMS beside the archive.

  • Build provenance Attestations

    SLSA provenance and an SBOM attestation, signed through Sigstore.

  • Supply chain posture OpenSSF Scorecard

    Scored continuously; CodeQL, Dependabot and DCO run on every change.

  • Vulnerability reporting security.txt

    A published disclosure route, not an inbox someone forwards.

  • Accessibility WCAG 2.2 AAA

    Enforced in CI across representative pages and three colour modes.

For risk and procurement

What a risk review asks. Where the answer is.

Each answer describes how the software works and where its evidence is. None of it is a certification, and none of it replaces your own assessment.

The questionThe answerWhere to check
Where does payment data go?Nowhere. Validation runs inside your infrastructure and makes no network calls; there is no hosted service holding your files.Data handling
Can we assess the software supply chain? (DORA ICT third-party risk)A CycloneDX SBOM, signed release tags with checksums, and build provenance attested through Sigstore, all verifiable without contacting us.Evidence above
What if the maintainer stops?The source is Apache-2.0 or MIT: you can build, run and fork it indefinitely. The governance page sets out how decisions are made, how releases are cut, and the plan for a second maintainer.Governance
How are defects and vulnerabilities handled?Private vulnerability reporting and a published security.txt. Security reports are acknowledged within 5 working days as a goal, not a guarantee.Maintenance policy
Does it know our bank’s rules?Not out of the box. Your own team can turn the bank’s usage guideline into a validated profile with the published guide and tooling, without the guideline leaving your network.Build a bank profile

Pain001 is free open-source software, dual-licensed Apache-2.0 or MIT, maintained in a personal capacity. There is no paid tier, no sales team and no one to call: everything a bank's review needs is published, so the review can be done without talking to anyone.

What the evidence pack holds#

One ZIP, rebuilt with every release, with no form in front of it:

  • the CycloneDX SBOM of the release;
  • SLSA build provenance and the Sigstore attestation, with step-by-step verification commands;
  • the signed tag and SHA256SUMS of every release file;
  • the OpenSSF Scorecard result;
  • security.txt and the vulnerability disclosure policy;
  • a data-handling statement: no network calls, no telemetry, no hosted service;
  • a DORA ICT third-party evidence map, from each question to the artefact that answers it, with no claim of compliance;
  • a licence summary (Apache-2.0 or MIT);
  • a pre-filled security questionnaire, CAIQ-lite style, as a spreadsheet;
  • the support and maintenance policy below;
  • the accessibility statement.

Free resources for your team#

Resource What it gives you
Maintenance policy Fixes, including security fixes, ship in the next release. There is no long-term-support line at present.
Build your own bank profile A step-by-step guide and tooling (template, validator, examples), so your team turns the bank's usage guideline into a validated profile in-house, with the data never leaving your network. Public, non-confidential profiles may be contributed to the repository.
Open integration recipes ERP or TMS CSV export to pain.001 mapping, batch and API pipeline patterns, pain.002 handling, and camt.052, camt.053 and camt.054 reconciliation through pain001[camt]. Contributions welcome.

Maintenance policy#

  • Fixes, including security fixes, ship in the next release and arrive by upgrading. There is no long-term-support line at present.
  • Security reports are acknowledged within 5 working days as a goal, not a guarantee.
  • There is no SLA and no out-of-hours cover.

What this is not#

No hosted service, no telemetry, no paid tier, no SLA and no certification. Nothing on this page certifies Pain001 against any regulation, and none of it replaces your own assessment.

Need paid help?#

Pain001's licence lets any firm support it commercially. The project has no commercial partners and takes no fees or referrals.

Contact#

Report a vulnerability through security.txt. Ask everything else in GitHub issues. The address contact@pain001.com is for confidential security matters only.

Questions a review asks#

It has been maintained since 2023, with signed, reproducible releases under a permissive licence, a published maintenance policy and an open governance model. Anyone can fork it or support it.

Nothing. There is no paid tier. The maintenance policy says what to expect, and the licence lets any firm offer commercial support independently.

Pain001 checks the ISO 20022 schema and the scheme rulebook. Your bank's own rules are a third layer: build a private profile with the guide and validate against it before you send a test file to the bank.