Raka svar för treasurers, betalningsdrift, ingenjörer och revisorer. Frågorna är formulerade som folk faktiskt ställer dem. För djupare tekniska detaljer, se den tekniska referensen.
För treasury- och finansledare#
Vad är pain.001, i ett stycke?
pain.001 är det ISO 20022-meddelande en kund skickar till sin bank för att initiera betalningsöverföringar — XML-efterträdaren till format som SWIFT MT101 och inhemska flatfiler. Banken validerar det mot ett schema och ett regelverk innan det accepteras. Pain001 (programvaran) producerar dessa filer från de data du redan har och bevisar att de är giltiga innan du skickar in dem.
Vad är skillnaden mellan pain.001 och pain.008?
Riktningen på flödet. pain.001 initierar betalningsöverföringar — du skickar pengar ut. pain.008 initierar autogiro — du drar in pengar du har rätt till enligt ett medgivande. Pain001 genererar båda: tio versioner av pain.001 (.001.03 till och med .001.12) och pain.008.001.02.
Vi skickar fortfarande MT101-filer. Hur brådskande är migreringen?
Brådskande. SWIFT pensionerade MT-meddelanden i kategori 1, 2 och 9 för gränsöverskridande interbankbetalningsinstruktioner i november 2025; företagskanaler som fortfarande tar emot MT gör det efter varje banks eget gottfinnande och på lånad tid. MT101-inläsaren konverterar befintliga MT101-flöden till validerad pain.001 utan att något behöver knappas in på nytt.
Vad betyder deadline för strukturerade adresser i november 2026 för oss?
Från slutet av november 2026 accepteras inte längre helt ostrukturerade postadresser i CBPR+-gränsöverskridande betalningar; adresser måste vara strukturerade eller hybrida — separata element som ort (
Vad kostar Pain001?
Ingenting. Kärnan är dubbellicensierad Apache-2.0 / MIT; kompletterande paket är Apache-2.0. Kommersiell användning, modifiering och vidaredistribution är tillåtna. Som jämförelse listas enbart SWIFT:s översättnings-SDK till €10,000–30,000 per år.
För betalningsdrift#
Varför avvisar banker betalfiler?
Fyra återkommande orsaker: schemabrott (fel element, fel version, fel namnrymd), felaktiga identifierare (IBAN-kontrollsummefel, felformade BIC-koder), trasiga kontrollsummor (NbOfTxs / CtrlSum som inte stämmer med transaktionerna) och tecken utanför den latinska ISO 20022-uppsättningen. Pain001 kontrollerar alla fyra innan filen existerar: JSON Schema-validering per post, mod-97-kontroll av IBAN och ISO 9362-kontroll av BIC, omräknade kontrollsummor, translitterering av teckenuppsättningen och slutlig XSD-validering av den renderade XML-filen.
Kan vi validera en fil utan att generera något?
Ja — pain001 --dry-run (eller underkommandot validate, eller POST /api/v1/validate). Slutkod 0 betyder giltig; 1 betyder att valideringen misslyckades, med fel på fältnivå. Koppla in det i CI eller i en checklista före inskickning.
Vilka SEPA-regelverk täcks?
Fem regelverk medföljer inbyggt: SEPA Credit Transfer (sepa-sct), SEPA Instant (sepa-inst), SEPA Direct Debit Core (sepa-sdd), SEPA B2B (sepa-b2b) och gränsöverskridande betalningsöverföring (xborder-ct). Använd --scheme för att se varje regel som godkänts eller underkänts.
Våra data ligger i Excel. Vad är haken?
Excel omvandlar i tysthet IBAN-liknande strängar till tal. Excel-inläsaren läser .xlsx/.xlsm direkt och stoppar tvärt om IBAN-kolumner innehåller numeriska celler — korruptionen fångas vid inläsning, inte hos banken.
Hur hanterar det en batch med 500,000 rader?
--streaming bearbetar indata i minnesbegränsade delar (som standard 1,000 transaktioner), där varje del skrivs som en egen XML-fil med korrekt omräknade kontrollsummor. REST-API:et erbjuder POST /api/v1/generate/async med jobbstatuskontroll av samma skäl.
För ingenjörer och arkitekter#
Hur integrerar vi det — bibliotek, CLI eller API?
Alla tre finns som fullvärdiga gränssnitt: ett typat Python-API, ett CLI med CI-vänliga slutkoder och en FastAPI-mikrotjänst (pain001 serve) med endpoints för synkron körning, asynkrona jobb, hälsokontroll och Prometheus-metrik. Samma valideringspipeline i botten, så resultaten skiljer sig aldrig mellan gränssnitten.
Är XML-genereringen verkligen säker mot flyttalsavrundning?
Belopp är decimal.Decimal hela vägen genom generering och regelverksvalidering — tolkade som exakta decimaltal, summerade som exakta decimaltal, renderade utan flyttalsrepresentation. Kontrollsummor räknas om från validerade poster och tas aldrig från indata.
Hur ser säkerhetsprofilen ut?
All XML-parsning går via defusedxml (som blockerar XXE- och entitetsexpansionsattacker); lxml finns inte i beroendeträdet. Indata passerar en path traversal-validerare. Docker-avbildningen körs utan root. En CycloneDX-SBOM genereras för kärnreleaser, och upptäckt av tredjepartsplugins kan stängas av helt med PAIN001_DISABLE_PLUGINS=1.
Hur upprätthålls kvaliteten?
100% rad- och grentäckning som hård CI-grind på kärnan (verifierbart: 3,828 rader, 926 grenar på 100%), strikt mypy, 100% docstring-täckning, säkerhetslintning med Bandit och pip-audit samt CodeQL-skanning. De kompletterande paketen håller samma disciplin med 100% täckning.
Kan vi utöka det för ett proprietärt format?
Ja — fyra entry-point-grupper för plugins (pain001.loaders, pain001.validators, pain001.schemes, pain001.writers). Excel-inläsaren är själv en plugin som använder det publika protokollet och fungerar därmed också som referensimplementation.
För revisorer och compliance#
Kan vi återskapa en fil som genererades förra kvartalet?
Ja. Lås paketversionen, spela upp samma indata igen, så är utdata deterministiska. Eftersom verktygskedjan är öppen källkod sträcker sig revisionsspåret in i själva kodvägen — inte bara till ett leverantörsintyg.
Lämnar betaldata vår miljö?
Nej. Varje komponent — CLI, bibliotek, REST-API, MCP-server, LSP — körs lokalt. Det finns ingen telemetri, inget SaaS-anrop, ingen extern valideringstjänst. MCP-servern talar enbart stdio och alla dess 17 verktyg är annoterade som skrivskyddade och idempotenta.
Vem underhåller Pain001?
Sebastien Rousseau, en Londonbaserad ledare inom fintech-utveckling, tillsammans med bidragsgivare från communityn. Utvecklingen sker öppet på GitHub, releaser publiceras på PyPI och ändringsloggen versioneras med varje release.