CAMT.053 Converter — and the Practical Alternative

What CAMT.053 actually is

CAMT.053 (BankToCustomerStatement) is part of the ISO 20022 family — the modern XML standard replacing older SWIFT MT messages. It delivers end-of-day statement data as richly structured XML: entries (Ntry) with amounts, credit/debit indicators (CdtDbtInd), booking and value dates, and structured references banks and corporates rely on for automated reconciliation.

A fragment gives the flavour:

<Ntry>
  <Amt Ccy="EUR">42.30</Amt>
  <CdtDbtInd>DBIT</CdtDbtInd>
  <BookgDt><Dt>2026-03-03</Dt></BookgDt>
  <NtryDtls>
    <TxDtls>
      <RmtInf><Ustrd>Card payment Office Supplies</Ustrd></RmtInf>
    </TxDtls>
  </NtryDtls>
</Ntry>

CAMT.053 vs the older MT940

CAMT.053 is the ISO 20022 successor to the SWIFT MT940 text format. Both deliver statement data for import, but CAMT.053 is XML-based, richer, and increasingly the SEPA-era standard, while MT940 is the legacy tag-based format still widely supported.

Why treasury and ERP systems ask for CAMT.053

Corporates use CAMT.053 for automated, high-volume reconciliation: treasury management systems and ERPs read the structured entries to match payments, post transactions and close cash positions without manual keying. The rich references are what make straight-through processing possible.

That richness is exactly why it must come from the bank — the codes are generated in the bank's systems, not printed on the customer statement. A CAMT.053 assembled from a PDF would be missing the very fields that justify using CAMT.053 in the first place.

Why a PDF can't become CAMT.053

A CAMT.053 file carries structured data a PDF never had: bank transaction codes, structured remittance information, precise entry references. A printed statement shows a human-readable summary of activity, not those machine codes. Fabricating them to fill an XML template would produce a file that looks compliant but carries guessed values — dangerous in an automated reconciliation.

FlowParse refuses that trade. It extracts what the statement truly holds and delivers it honestly, rather than manufacturing a standard it can't faithfully populate. A reconciliation engine that silently matches on invented codes is worse than one that never ran.

What FlowParse gives you instead

Depending on what your downstream system accepts, FlowParse produces a format that works:

When you genuinely need CAMT.053 — and where to get it

If your treasury process depends on CAMT.053, get it from the source: your bank's electronic-banking or host-to-host channel provides it directly, with all the real codes intact. That is the file your reconciliation engine should consume.

FlowParse is for the gaps — historical statements, accounts without a CAMT feed, foreign banks, or documents that only exist as PDFs — where you still need the transactions in a structured, usable form even though no native feed exists.

What FlowParse reads from the statement

From the PDF, FlowParse captures the account summary and every transaction — date, description, a signed amount, and the running balance — with opening and closing balances preserved. It is the same activity CAMT.053 reports, minus the bank-only machine codes, delivered as clean data you control.

For most bookkeeping and posting purposes that activity is all you need; the structured bank codes matter chiefly for fully automated, high-volume matching, which is precisely the case where you should be using the bank's own CAMT feed.

flowparse.io

Clean XML you can map yourself

If your integration expects XML, FlowParse's structured statement XML is a solid starting point: well-formed, namespaced, one element per field. Where a system strictly needs ISO 20022, your integration layer can map that clean XML into the target schema — with honest field data underneath rather than fabricated codes.

That mapping approach keeps the responsibility where it belongs: FlowParse gives you reliable transaction data, and your integration decides how to dress it for a specific standard.

How to turn your statement into usable data

Consolidate many statements

Upload up to 100 statements and Smart Merge combines them into one reconciled dataset with duplicate detection and a source-file reference, then exports in your chosen format — turning a backlog into structured data in minutes.

A consolidated quarter or year is often easier for a downstream system to ingest than a pile of monthly files, and the duplicate detection removes the overlapping opening/closing rows that would otherwise double-count.

Reconciled before export

FlowParse reaches around 98% field-level accuracy on standard layouts and validates opening balance plus transactions against the closing balance, flagging any discrepancy in the editable preview. You feed your systems data you have checked.

Handing an ingestion pipeline pre-reconciled data means a bad file is caught at review, not three steps downstream when it has already affected a cash position.

Sensitive data, handled properly

Uploads run over TLS, processing is EU-hosted, the source PDF is deleted immediately after processing, and your documents are never used to train AI models.

With nothing retained after processing, there is no growing repository of corporate statements to secure or to breach.

flowparse.io

CAMT.053 among its siblings

CAMT.053 is one of a family. CAMT.052 is the intraday report, CAMT.053 the end-of-day statement, and CAMT.054 the debit/credit notification. They share the ISO 20022 XML grammar but serve different moments in the cash cycle, which is why a treasury system often consumes several of them together.

Understanding that helps set expectations: FlowParse works from the printed end-of-day statement, so the closest analogue is the data a CAMT.053 would carry. The intraday and notification messages are event feeds from the bank with no PDF equivalent at all, so there is nothing to reconstruct them from.

Why CAMT is replacing MT, slowly

The banking world is midway through a long migration from the legacy SWIFT MT messages to ISO 20022, driven by SEPA and by cross-border payment reforms. CAMT.053 is the statement piece of that shift, prized because its structured remittance data supports automatic matching that the terse MT940 could only approximate.

During a migration measured in years, many organisations live with both — some accounts on CAMT, some on MT940, some with only PDFs. FlowParse covers the last case, so a gap in your bank's rollout doesn't leave a gap in your books.

Structured versus unstructured remittance

Much of CAMT.053's value is in its remittance information — structured references that tie a payment to an invoice, enabling straight-through cash application. A PDF statement usually shows only the unstructured description a human would read, not the structured reference codes.

FlowParse captures that human-readable description faithfully, which is enough to match many transactions by payee and amount. What it cannot invent is a structured creditor reference the statement never printed — and where that structured matching is essential, the bank's own CAMT.053 is the right source.

Reviewing the data before you trust it

Automated reconciliation is only as safe as the data behind it, which is why the editable preview matters even in a machine-to-machine workflow. Before any statement XML or CSV leaves FlowParse, low-confidence fields and balance breaks are surfaced for a human to confirm, so a smudged figure or a misread page is caught at the source.

That review step is the honest counterweight to convenience. You are not asking a treasury system to trust a black box; you are handing it data a person has checked and the engine has proven to balance. For anything feeding a cash position, that combination of human review and arithmetic proof is exactly the assurance you want.

From gap-filler to a standard workflow

Teams often adopt this to plug a one-off gap and then keep it, because the same path handles every awkward case the native feed misses. A newly acquired subsidiary on an un-onboarded bank, a due-diligence exercise over historical accounts, a quick reconciliation of a foreign account — all become routine once statement PDFs reliably become structured data.

What starts as a workaround becomes the standard answer to 'we don't have a feed for this.' The bank's CAMT.053 stays the source of truth where it exists; FlowParse becomes the dependable fallback everywhere it doesn't, and the finance team stops treating feedless accounts as a problem.

Statements, payments and the wider ISO family

It is easy to confuse the message families. The camt messages report what happened to your account — statements and notifications the bank sends you. The pain messages (payment initiation) go the other way: instructions you send the bank to make payments. CAMT.053 sits firmly on the reporting side.

That matters here because a PDF statement is, by definition, reporting after the fact. So the honest analogue of what FlowParse produces is camt-style statement data, never a pain instruction. Understanding which side of the conversation you are on keeps the expectations straight about what a converted PDF can and can't be.

How banks actually deliver CAMT.053

CAMT.053 typically arrives through a corporate channel: a host-to-host connection, an EBICS link in Europe, or a download in the bank's cash-management portal. These channels carry the fully structured message straight into a treasury or ERP system, which is exactly why the format is worth the setup for high-volume operations.

None of those channels exist for a historical PDF, a foreign account you don't have cash-management access to, or a closed account. That is the boundary this page is about: where the bank's CAMT delivery reaches, use it; where it doesn't, FlowParse turns the PDF you do have into structured data you can work with.

A worked example: PDF to reconciled cash

Imagine a treasury team that gets CAMT.053 for its main euro accounts but holds a legacy account at a bank that never enabled the feed, with only monthly PDFs. Those transactions still need to appear in the cash position.

They run the PDFs through FlowParse, export structured statement XML, and their integration maps it into the same ingestion path the real CAMT files use. The legacy account's activity now shows up alongside everything else — reconciled and reviewed — with the team fully aware it came from a PDF rather than a native feed, and no fabricated codes anywhere in the flow.

One cash view across many banks

Corporates rarely bank in one place, and CAMT.053 exists partly to give a single structured view across many banks. The weak point is always the account or bank that hasn't been onboarded to the feed — it leaves a blind spot in the cash picture.

Feeding those stragglers through FlowParse closes the blind spot with honest data. The consolidated view stays complete, and the finance team knows precisely which lines came from a native CAMT feed and which were reconstructed from a statement — which is far better than a gap or a guess.

Who this is for

Treasury and finance teams whose systems expect CAMT.053 but who face statements without a native feed, integration developers who need clean structured data to map, and anyone who would rather have honest transaction data than a plausible-looking but fabricated ISO 20022 file.

Where the real CAMT.053 exists, use it; where it doesn't, FlowParse fills the gap with structured data you can trust and map yourself. For most teams that means fewer blind spots in the cash picture and a repeatable answer for every account the native feed doesn't reach.

Frequently asked questions

Related