camt.060 ISO-20022 message

Published on

08/09/2026

Updated on

08/09/2026

Reading time

3 min

The camt.060 is the ISO 20022 AccountReportingRequest message. An account owner uses it to ask its account servicing institution for a specific account report. It is therefore the request message belonging to the reporting messages camt.052, camt.053 and camt.054.

Definition

camt.060 belongs to the ISO 20022 Cash Management (camt) family and comes from the same message set as the reports themselves: Bank-to-Customer Cash Management. It was submitted by Swift; the current version listed in the ISO 20022 catalogue is camt.060.001.07 (AccountReportingRequestV07, last updated in March 2026).

According to the standard the message is “sent by the account owner, either directly or through a forwarding agent, to one of its account servicing institutions”. It creates no booking and changes no payment – it only triggers the production and delivery of a report.

Push and pull

Account information normally reaches the customer without being asked for: the end-of-day statement camt.053 after close of business, the intraday report camt.052 at agreed intervals, the debit/credit notification camt.054 when an entry is posted. That schedule is agreed between bank and customer and then runs automatically.

camt.060 covers the opposite case: the account owner wants a particular report outside that schedule – an intraday report in the middle of the day, a repeat of a statement that was not delivered, or a report for a defined period.

Scheduled – the bank delivers as agreedbankcustomercamt.052 / camt.053 / camt.054 on the agreed scheduleOn request – the account owner asks for a specific reportcustomerbankcamt.060 – account, requested report type, periodthe requested camt.052 / camt.053 / camt.054

Message structure

camt.060 is lean. Besides the group header (GrpHdr) it carries one or more reporting request blocks RptgReq with these key elements:

  • Id – reference of the request.
  • ReqdMsgNmId – the decisive parameter: it names which report is to be produced, that is camt.052, camt.053 or camt.054.
  • Acct – the account concerned, normally by IBAN.
  • AcctOwnr / AcctSvcr – account owner and account servicing institution.
  • RptgPrd or FrToDt – the period the report is to cover.
  • ReqdBalTp and ReqdTxTp – optional restrictions to particular balance or transaction types.
  • RptgSeq – request by statement number, for instance to obtain a specific statement again.

Usage

Germany and EBICS

In German corporate banking camt.060 plays hardly any role. Account information is retrieved in the EBICS protocol through order types – C52 for camt.052, C53 for camt.053 and C54 for camt.054; the legacy formats MT940 and MT942 have order types of their own. The period is passed as a parameter of the retrieval, so a separate request message is not needed. Accordingly, camt.060 does not appear among the order types of the DFÜ agreement.

Other markets and channels

The Swiss Payment Standards likewise cover only camt.052, camt.053 and camt.054; camt.060 is explicitly outside the scope of their implementation guidelines. The message becomes relevant where no protocol with its own retrieval mechanism sits in between – in host-to-host connections, in API-based channels and in bilateral arrangements where the customer sends a reporting request as a message in its own right.

The practical significance of camt.060 therefore depends less on the standard than on the channel: the standard provides for the message, the applicable rulebook decides whether it is used at all.

Relevance for banks and payment service providers

  • Settle the channel first. Before implementing, check whether the rulebook in use knows camt.060 at all. In EBICS constellations the route runs through order types, not through the message.
  • ReqdMsgNmId and the period are the core. Both determine what the customer actually gets back. Vague period definitions are the most common cause of unexpected report content.
  • Plan for duplicate reports. Where a report is requested in addition to the regular schedule, the customer may receive entries more than once. Statement numbers and sequence data should be evaluated in downstream processing.

Sources for specifications