camt.052 vs MT942: The Intraday Report, Field by Field

camt.052 is the ISO 20022 BankToCustomerAccountReport and MT942 is the SWIFT Interim Transaction Report — the two intraday messages a bank sends between statements — and the whole difference between them and their end-of-day siblings is that neither is a statement: MT942 carries no balances, camt.052 may carry none, and camt.052 may include pending items as well as booked ones. The end-of-day trio is covered elsewhere — the camt.053 field walkthrough, the MT940 tag walkthrough, the BAI2 record walkthrough — and the camt.054 notification is the third member of the camt family. This post is for the day an intraday feed is on the table: what each message actually holds, where the two are structurally different, and the places two banks' published guides show them diverging from the standard.

The usual reason to care is an intraday cash position or same-day reconciliation. Both messages exist so the treasury does not wait for the statement; both are routinely fed into the same importer as the statement; and both are wrong to treat as one. The MT940 vs camt.053 vs BAI2 comparison explains the family choice; here the question is what the intraday message is.

What ISO says camt.052 is for

The Message Definition Report is unusually direct. The BankToCustomerAccountReport "is sent by the account servicer to an account owner or to a party authorised by the account owner to receive the message. It can be used to inform the account owner, or authorised party, of the entries reported to the account, and/or to provide the owner with balance information on the account at a given point in time." The usage section lists what it can be used for — "report pending and booked items; provide balance information" — and closes with the sentence that decides most design arguments: "For a statement, the Bank-to-Customer Account Statement message should be used."

Three things in that scope drive everything below. Reported entries, not booked ones. And/or balance information — a report is allowed to be one or the other. And pending items are in scope, which no statement carries.

Payments Canada's usage guideline for camt.052.001.08 restates the same scope and usage text verbatim and restricts the base message for its own community — which is what a usage guideline is, and what your bank's version of it will do too.

The skeleton, and where it differs from camt.053

camt.052 has three building blocks — GroupHeader, Report, SupplementaryData — mirroring camt.053's GroupHeader, Statement, SupplementaryData. Inside <Rpt> the shape is the one a camt.053 reader already knows: identification, an optional pagination block, sequence numbers, a creation timestamp, an optional from-to period, the account, then balances and entries.

The multiplicities come straight from the MDR's element tables for camt.052.001.08 and camt.053.001.08. The one worth writing on the wall is the balance: [0..*] on the report, [1..*] on the statement. Every camt.053 importer I have seen assumes a balance exists. Point it at a camt.052 feed and the first report with movements and no <Bal> block is a null reference in the cash position at 11:20.

Entry status: the field that makes it a report

Each <Ntry> carries a mandatory <Sts>, and in the .08 message it is an external code set (ExternalEntryStatus1Code) rather than an enumeration baked into the schema. The published list distinguishes booked from pending from information-only, and an intraday report is where the non-booked values actually appear — a statement contains booked entries only, so a camt.053 parser can get away with never reading the status. A camt.052 parser cannot: a pending entry applied to the position and then booked in the next report is a double count, and a pending entry that is later rejected never becomes a booking at all.

Two rules that survive contact with real feeds:

• Position from booked, exposure from pending. Apply booked entries to the running balance; show pending ones as expected movements, never as cash.
• Key on the bank's entry reference, not on amount and date. The same booking can appear as pending in one report, booked in a later one, and again in the statement. The reference is what lets you recognise it; amount-and-date matching will happily count it three times.

Balances on an intraday report

When a bank does send balances on a camt.052, the types come from the same external code set the statement uses (ExternalBalanceType1Code). A statement leans on the opening and closing booked and available types; an intraday report typically leans on the interim types — ITBD, interim booked, and ITAV, interim available — which say "this is where the account stands at the time in <CreDtTm>, not at end of day". Which of these your bank populates, and whether the interim balance includes or excludes pending items, is not in the standard; it is in the bank's guide, and it is the first question to ask before building anything on it.

"

Neither intraday message is a statement. MT942 has no balances; camt.052 is allowed to have none. Design the position as movements applied to the last statement, not as a reading of the report.

MT942: the whole message in ten tags

MT942 predates all of this and is correspondingly compact. HSBC's usage guideline describes the message as eleven building blocks; Rabobank's format description says what it is for in one sentence — the report "reports debits or credits to the account since the last account statement was made available. Only intraday transactions are reported." The chain, with the multiplicities both guides give:

What is absent is the point: there is no :60a: opening balance and no :62a: closing balance. The :90D:/:90C: totals are the only arithmetic the message offers, and they check the report against itself — the count and sum of the :61: lines above them — not against a balance. An MT942 importer therefore has exactly one integrity test, and it is worth running: if the sum of debit :61: lines does not equal :90D:, the file is truncated or the parser is wrong.

:13D: deserves a sentence. It is the only timestamp in the message and it carries a sign and offset, so two banks reporting "as of 14:30" can mean different instants. A position that merges intraday reports from several banks needs to normalise this field to one clock before comparing anything.

Where the two banks diverge from the standard

This is the part no standard tells you and both guides do.

Rabobank's format description is explicit that its MT942 export "is not completely according to SWIFT format", and lists the deviations: :28C: is a fixed 1/1; :34F: is present twice with fixed values <currency>C0,00 and <currency>D0,00; :90C: and :90D: omit the number of entries between the tag and the currency, "deviating from the SWIFT standard"; the transaction type code in :61: is a fixed NMSC for Rabo accounts; and the whole message can exceed 2,000 characters. Every one of those breaks a parser written from the field formats above.

HSBC's guideline keeps the standard formats but states its own conventions: :28C: is always padded to five digits (:28C:00235/0001), the account in :25: is reported without hyphens, and :86: is "populated with unstructured information of transaction description downloaded from the bank", with content that "depends on the nature of the underlying transaction/practice of the country".

Two banks, two different things done to the same tag. The lesson is the one every post in this cluster ends on: the bank's guide is the contract, and an intraday feed needs one parser profile per bank exactly as the statement does.

camt.052 or MT942: which one to ask for

If the bank offers both, the answer is usually the ISO message, for three reasons that are about the data rather than the format war.

• Structure. camt.052 carries the entry status, typed balances, the bank transaction code and structured references. MT942 carries a :61: line and whatever the bank put in :86:.
• Pending items. camt.052 can say an item is pending. MT942 has no status at all — everything in it is presented as booked.
• Pagination and duplicates. camt.052 has <RptPgntn> and <CpyDplctInd>; MT942 has :28C: and the bank's discipline.

Ask for MT942 when the receiving system only parses FIN, when the bank's camt.052 is a thin wrapper that carries no more than its MT942 does (compare the two guides — it happens), or when the intraday feed is a stopgap on the way to a migration that is already scheduled.

What usually goes wrong

• Feeding the intraday message into the statement importer. It parses — the shapes are similar enough — and then a report with no balance, or a pending entry, silently corrupts the position. Route intraday messages to a path that expects both.
• Anchoring on the report. The position is the last statement's closing balance plus booked intraday movements, reset when the next statement lands. An interim balance in a camt.052 is a cross-check, not the anchor.
• Matching on amount and date. Pending, then booked, then on the statement: the same movement three times. Key on the bank's entry reference.
• Ignoring :34F:. A non-zero floor limit means small movements are deliberately missing from the report. It is a one-line check and it prevents a week of "why does intraday never reconcile".
• Assuming one :28C: convention. One bank pads, one bank fixes it at 1/1, a third increments it. Sequence checks on MT942 have to be configured per bank, not written once.

Once the intraday feed is in, the same statement data meets the same matching problem the end-of-day one does — and that matching step is where a redesign pays off. The bank reconciliation teardown splits it into what stays deterministic (amount, date, reference within tolerance), what an AI step can read (the free text in :86: or <AddtlNtryInf>), and what stays with a named human.

See also the camt.053 field walkthrough, the camt.054 notification and the MT940 tags line by line.