List every supported ISO 20022 camt.05x message type and its name.
Use this first, before any validation or generation call, to discover the
exact ``message_type`` strings this server accepts. For the return-reason
codes rather than message types, call ``list_return_reasons`` instead.
Returns a list of ``{"message_type": ..., "name": ...}`` dictionaries, one
per supported message type (e.g. ``camt.053.001.14``).
List every known ISO external return reason code with its name.
Use this to discover the ``reason_code`` values that ``filter_entries`` and
``generate_reversal`` accept (e.g. ``AC04`` Closed Account). For the
supported message types rather than reason codes, use ``list_message_types``.
Returns a list of ``{"code": ..., "name": ...}`` dictionaries (e.g.
``{"code": "AC04", "name": "Closed Account Number"}``).
List only the required input field names for a camt message type.
Use this for a quick checklist of the mandatory columns before building
reversing-entry records. When you need full type/format constraints (not
just which fields are required), call ``get_input_schema`` instead.
Args:
message_type: A supported ISO 20022 camt.05x message type.
Return the full JSON Schema for a message type's flat input record.
Use this to learn every field, its type, and its constraints before
assembling records, or to drive a form/UI. For just the required-field
names use ``get_required_fields``; to actually check records against this
schema use ``validate_records``.
Args:
message_type: A supported ISO 20022 camt.05x message type.
Validate flat records against a message type's input JSON Schema.
Use this on in-memory reversing-entry records to catch structural/type
errors per row before generation. To validate a whole camt.05x *document*
(XML) against its XSD instead, use ``validate_statement``.
Returns a report ``{"valid": bool, "total": int, "valid_count": int,
"errors": [...]}``.
Args:
message_type: A supported ISO 20022 camt.05x message type.
records: One or more flat reversing-entry records to validate.
Validate a single financial identifier (IBAN, BIC, or LEI).
Use this for a one-off identifier check with a clear pass/fail. To validate
identifiers embedded across a whole batch of records, prefer
``validate_records`` rather than calling this per field.
Returns ``{"kind": str, "value": str, "valid": bool}``.
Args:
kind: One of ``"iban"``, ``"bic"``, or ``"lei"`` (case-insensitive).
value: The identifier value to check.
Parse an incoming camt.05x statement XML string into structured data.
Use this to turn a raw statement into a navigable dict (header, statements,
accounts, balances, entries). To pull just the flat entry list use
``list_entries``; to only check the document is schema-valid use
``validate_statement``.
Returns the parsed document as a JSON-serialisable dict (group header plus
statements, each with its account, balances, and entries), or an
``{"error": ...}`` payload if the XML cannot be parsed.
Args:
xml: The raw statement XML as a string.
Convert a legacy SWIFT MT940 statement into a camt.053 structure.
Use this as the Phase-1 migration wedge: SWIFT MT940 customer statements
retire in **November 2028**, so this tool bridges the gap by turning raw
MT940 text into the same JSON-serialisable camt.053 document shape that
``parse_statement`` returns (group header plus statements, each with its
account, balances, and entries). Downstream tools (``list_entries``,
``filter_entries``, ``classify_entry``, ``export_journal``) then work on the
result unchanged.
Wraps the ``camt053-loader-mt940`` library's ``parse_mt940``; the MT parsing
itself is delegated (no MT grammar is reimplemented here). The resulting
``ParsedDocument`` is serialised with the same ``to_dict()`` the server's
other parse tools use, so agents get a consistent structure. Nothing is read
from or written to disk.
Returns the converted document as a JSON-serialisable dict, or an
``{"error": ...}`` payload if the MT940 text cannot be parsed (e.g. a
missing ``:20:`` reference or a malformed balance / statement line).
Args:
mt940_text: The raw MT940 statement text as a string.
Convert a legacy SWIFT MT942 interim report into a camt.052 structure.
Use this as the Phase-1 migration wedge for intraday reporting: SWIFT MT94x
messages retire in **November 2028**, so this tool bridges the gap by
turning raw MT942 *Interim Transaction Report* text into the same
JSON-serialisable camt.052 (Bank-to-Customer Account **Report**) document
shape the server's parse tools return (group header plus statements, each
with its account, balances, and entries). MT942 is the intraday sibling of
MT940: where MT940 maps to camt.053 (end-of-day statement), MT942 maps to
camt.052, so the resulting ``message_type`` is ``camt.052.001.08``.
Downstream tools (``list_entries``, ``filter_entries``, ``classify_entry``,
``export_journal``) then work on the result unchanged.
Wraps the ``camt053-loader-mt942`` library's ``parse_mt942``; the MT parsing
itself is delegated (no MT grammar is reimplemented here). The resulting
``ParsedDocument`` is serialised with the same ``to_dict()`` the server's
other parse tools use, so agents get a consistent structure. Nothing is read
from or written to disk.
**Documented model limitation.** The ``camt053`` typed model is
camt.053-statement-oriented: it has no dedicated field for camt.052's
floor-limit (``<Lmt>``) or transaction-summary (``<TxsSummry>``) blocks.
Rather than drop that data, the loader surfaces it on the balance list using
clearly proprietary ``type_code`` values so consumers can recognise and
filter them: ``:34F:`` floor limits become ``FLIMD`` / ``FLIMC`` balances,
and ``:90D:`` / ``:90C:`` entry-count summaries become ``SUMD:<count>`` /
``SUMC:<count>`` balances (the ISO ``NbOfNtries`` count is encoded after the
colon; the sum is the balance ``amount``). See the loader's README.
Returns the converted document as a JSON-serialisable dict, or an
``{"error": ...}`` payload if the MT942 text cannot be parsed (e.g. a
missing ``:20:`` reference or a malformed floor-limit / summary / statement
line).
Args:
mt942_text: The raw MT942 interim transaction report text as a string.
Validate an incoming camt.05x statement XML against its XSD schema.
Use this to confirm a document is well-formed and schema-valid before
processing it. This checks XSD conformance only; for the Nov 2026 CBPR+
business rules use ``check_cbpr_readiness``, and to extract the data use
``parse_statement``.
Detects the document's message type, validates it against the matching
ISO 20022 schema, and returns a report ``{"valid": bool, "message_type":
str, "errors": [...]}``. A well-formed but schema-invalid document yields
``valid=False`` with a populated ``errors`` list (and the detected
``message_type``); a valid one yields ``valid=True`` with no errors.
Returns an ``{"error": ...}`` payload instead if the XML cannot be parsed
(e.g. it is malformed or is not a camt ``Document``).
Args:
xml: The raw statement XML as a string.
Check a camt.053 statement against the CBPR+ Nov 2026 acceptance rules.
Use this to audit a statement for the business-rule changes (schema
version, structured postal addresses) enforced from the Nov 2026 cutover.
For plain XSD schema validity use ``validate_statement`` instead; for just
the cutover date use ``get_cbpr_cutover_date``.
A coordinated CBPR+ / Fedwire / CHAPS / T2 cutover lands on
**14-16 November 2026**: unstructured-only postal addresses get rejected,
``camt.110/111`` exceptions and investigations become mandatory, and T2S
R2026.NOV upgrades camt.053 / 054 to schema revision MR2026.
This tool walks the supplied payload and reports every issue that will
fail the Nov 2026 acceptance rules:
* **Schema version** vs the CBPR+ current set (``camt.053.001.08`` /
``camt.053.001.13``); ``.02``-``.07`` are flagged as deprecated
warnings; unknown / non-camt.053 namespaces as errors.
* **Postal addresses**: every ``<PstlAdr>`` is classified as fully
structured, hybrid, or **unstructured-only** (``<AdrLine>`` without
``<TwnNm>`` + ``<Ctry>`` siblings, the Nov 2026 reject case).
Returns a dictionary ``{"cbpr_ready": bool, "schema_version": str | None,
"checked_at": ISO-8601 UTC, "cutover_date": "2026-11-16",
"issues": [...], "summary": {...}}``. ``cbpr_ready`` is ``True`` iff no
``severity="error"`` issue was raised. An ``{"error": ...}`` envelope
is returned instead if the XML is malformed or refused by the
hardened pre-flight (DOCTYPE / ENTITY / oversized payload).
Args:
xml: The raw camt.05x statement XML as a string.
Return the official CBPR+ / Nov 2026 cutover date as ISO 8601.
Use this to quote the enforcement date directly, without parsing a
document. To actually audit a statement against the rules that take effect
on that date, call ``check_cbpr_readiness`` instead.
The cutover (``2026-11-16``) is the date after which the rules checked
by ``check_cbpr_readiness`` are enforced by the major clearing systems;
payments that fail will be rejected at receive-time. Surfaced as a
discrete tool so agents can quote it directly without having to call
a readiness check first.
+12 more tools listed on main page