Show HN: Iso20022.js – Create payments in 3 lines of code

Original Article ↗ Hacker News Discussion ↗

Overview of iso20022.js

  • Typescript/Node library to create ISO 20022 payment messages, primarily PAIN (payment initiation) XML.
  • Main value: exposes ISO 20022 models in a typed, developer-friendly way, rather than dealing with raw XML/XSD.
  • Output is an XML payload that can be uploaded to banks (typically via SFTP or other bank-specific channels).

“3 Lines of Code” Debate

  • Landing page claims “create payments in 3 lines of code.”
  • Several people argue it’s really “3 steps” plus large configuration objects, so the claim feels marketing‑stretched.
  • Others consider it fair: import, instantiate, call; the long bits are data, not extra API calls.
  • Consensus: wording could be more precise, but the ergonomics still look good.

What the Library Does and Does Not Do

  • It is an ISO 20022 XML builder/encoder, not a payment processor.
  • It does not handle:
    • Bank connectivity (SFTP, SWIFT, VPNs).
    • Authentication, signing, or encryption.
    • Certification with payment schemes.
    • Status feedback (pain.002, webhooks-equivalent) yet, though ingesting status reports is on the roadmap.

ISO 20022 Context and Use Cases

  • ISO 20022 is a broad XML standard for financial messaging: cross-border, high-value, retail, real-time payments, statements, etc.
  • Widely used in SEPA and increasingly mandated in other systems (Fed networks mentioned).
  • Typical users are institutions doing high-volume bank transfers (payroll, insurance, treasury), not small apps replacing Stripe.

Complexity of Payments vs. Message Formatting

  • Multiple commenters stress that generating valid ISO 20022 XML is the easy part.
  • The hard parts: fraud/risk, error handling, reversals/refunds, reconciliation, accounting, audit logging, atomicity, retries, and multi-bank quirks.
  • Bank integrations often involve strict rulebooks, test environments, security setups, and per-bank differences in limits and schemas.

Standards, Variants, and XML Discussion

  • ISO 20022 is large (hundreds of message types) and extensible; banks frequently add custom fields or bespoke flavors.
  • This extensibility both enables evolution and causes interoperability pain.
  • Some note that XSD-to-code generation already exists in many languages; value here is developer ergonomics in the JS/TS ecosystem.

Security, Stack, and Dependencies

  • Concerns raised about using Node/NPM for finance due to ecosystem culture, dependency-chain risks, and JS number handling.
  • Others note the package has a relatively small dependency tree, but dependency auditing remains critical.