Camt Laravel Package

Product Decisions This Supports

• Build vs. buy for bank statement ingestion. CAMT.052/053/054 are ISO 20022 XML schemas with version-specific namespaces and nested Ntry/TxDtls structures. Using this package replaces weeks of hand-rolled XML mapping with a versioned parser, so the decision shifts from "can we build a parser?" to "which versions do our banks actually send?"
• Roadmap scoping for reconciliation features. Enables a concrete sequence: import → normalize → match to invoices/payments → expose unmatched items. The package is read-only, so it answers the ingest question only; matching logic, ledger posting, and UI remain your product surface.
• Multi-bank support as a feature, not a per-bank project. CAMT is the common format across SEPA/EU banks (and increasingly non-EU). Supporting a new bank becomes a transport + version-check task rather than a new parser, which changes pricing/packaging decisions around "supported banks."
• Cash positioning and treasury views. CAMT.052 (intraday) supports near-real-time balance dashboards; CAMT.053 (end-of-day) supports daily reconciliation and closing; CAMT.054 (notifications) supports instant payment/collection eventing. Each maps to a distinct feature and a distinct customer segment.
• Data model and idempotency decisions. The package exposes message-level identifiers and entry references, which lets you decide on dedupe keys, re-import behavior, and audit trails before you build — cheaper to decide now than to migrate statement data later.
• Buy/partner decisions for the transport layer. This package parses files; it does not fetch them. It sharpens the decision to build vs. buy EBICS/SFTP/bank-API connectivity as a separate workstream.

When to Consider This Package

Good fit when:

• You're on PHP/Laravel (or any Composer project) and need to read CAMT.052, .053, or .054.
• Your banks' versions appear in the support matrix — note the table has gaps (e.g., camt.052.001.03/.05/.10/.11 and camt.053.001.01/.05 unsupported), so validate against actual bank samples before committing.
• You need parsing only, with your own persistence, matching, and UI on top.
• MIT licensing and a self-contained dependency are acceptable — no vendor contract, no per-message fees.
• You can tolerate a small maintainer surface (97 stars, low dependent count) by wrapping the library behind your own adapter.

Look elsewhere or plan to extend when:

• You need CAMT.056/057 (payment cancellation/status), PAIN message generation, or CAMT versions absent from the matrix.
• You need writing/serialization, not just reading.
• You require vendor SLAs, guaranteed schema updates, or support for bank-specific CAMT variants and extensions.
• You need a licensed, certified connector (EBICS, PSD2 APIs) — parsing is a small slice of that problem.
• You're not on PHP, or you want one library that also covers MT940/MT942 legacy statements without a second dependency.
• Compliance review requires a maintained project with a security disclosure process and broad production adoption; budget time to fork or vendor the code if that's a hard gate.

How to Pitch It (Stakeholders)

For executives: EU/SEPA bank statements arrive as ISO 20022 CAMT XML files. Rather than fund a bespoke parser, we can adopt a small MIT-licensed PHP library that already handles the three message types our customers care about — intraday balances, end-of-day statements, and debit/credit notifications. This shortens time-to-market for bank reconciliation and cash-positioning features by an estimated several weeks of engineering, at effectively zero licensing cost. The main risk is that the project is small and single-maintainer, so we should isolate it behind an internal interface and pin the version; switching cost stays low. Total exposure is a contained, reversible dependency decision, not a platform bet.

For engineering: Composer dependency, MIT, tested with CI and coverage, latest release August 2025. Read-only parser for CAMT.052/053/054 with a documented per-version support matrix — verify against real bank samples first, as several versions are unsupported. Wrap it in a StatementParser port inside our app, pin the version in composer.json, add golden-file tests per bank and per CAMT version, and keep transport (EBICS/SFTP/API) as a separate module. Treat the library as a swappable adapter so a fork or replacement is a one-class change.

Recommendation: Proceed with a short spike — parse three real statement files from our two largest banks, confirm version coverage and field fidelity (entry references, amounts, currencies, counterparties), then adopt behind an adapter if the spike passes.