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

A new TypeScript library, iso20022.js, aims to make generating ISO 20022 payment messages as simple as three lines of code, prompting debate over whether it meaningfully simplifies a problem that many see as already solved by schema-based code generation. Commenters note that while the tool can streamline creation of standards-compliant XML for bank transfers (SEPA, SWIFT, ACH, etc.), the hard parts of payments remain elsewhere: bank-specific variants of the standard, security, certification, transport (often via SFTP), and large operational and compliance burdens. Some also question the suitability of the Node.js ecosystem and NPM dependency chains for financial software, even as others see value in a modern, developer-friendly interface to an increasingly important global payments standard.

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.