camt.053.001.08 XSD schema and business logic

Learn how to generate valid camt.053.001.08 messages for your ISO 20022 message-based integration to Mambu Payments (formerly Numeral)

A camt.053.001.08 is a Bank to Customer Statement received by Mambu Payments to report all booked entries and balance information for one or more accounts over a given period. It is the primary message used for end-of-day cash reporting and reconciliation.

1. Message definition and structure

Access the message definition and structure here.

Document
└── BkToCstmrStmt (BankToCustomerStatement)
    ├── GrpHdr (GroupHeader)          — Message-level metadata
    └── Stmt [1..*] (Statement)       — One block per account or per period
        ├── Account identification
        ├── Bal [1..*] (Balance)      — Opening, closing, and optional interim balances
        └── Ntry [0..*] (Entry)       — One block per booked transaction
            └── NtryDtls (EntryDetails)   — Optional transaction-level detail
                └── TxDtls (TransactionDetails)

2. Business rules

2.1 Group Header (GrpHdr)

XML TagNamePresenceRules
MsgIdMessage IdentificationMandatoryMust be unique per message. Maximum 35 characters.
CreDtTmCreation Date and TimeMandatoryISO 8601 datetime (YYYY-MM-DDThh:mm:ss) indicating when the message was created. Always expressed in UTC.
MsgRcptMessage RecipientOptionalIdentifies the account owner or authorised party receiving the statement.
MsgPgntnMessage PaginationOptionalPresent when the statement is split across multiple message files. Contains PgNb (page number) and LastPgInd (boolean indicating the final page).

2.2 Statement (Stmt)

Each Stmt block corresponds to one account for one reporting period.

XML TagNamePresenceRules
IdStatement IdentificationMandatoryUnique identifier for this statement within the message.
ElctrncSeqNbElectronic Sequence NumberOptionalSequential counter incremented by one for each statement delivered for the same account. Allows the recipient to detect gaps or duplicate deliveries.
CreDtTmCreation Date and TimeOptionalDatetime the statement was generated. If absent, the GrpHdr/CreDtTm applies.
FrToDtFrom/To DateOptionalThe reporting period covered by this statement, expressed as a date range (FrDtTm and ToDtTm). Used when a single Stmt covers multiple business dates.
Acct.Id.IBANAccount IBANMandatoryThe IBAN of the account to which this statement belongs. Used to map each Stmt block to the correct internal or external account in your system.
Acct.CcyAccount CurrencyOptionalThe currency of the account (ISO 4217 alpha code, e.g. EUR).
Acct.SvcrAccount ServicerOptionalBIC of the institution servicing the account.

2.3 Balances (Bal)

Each Stmt must contain at least two balance entries: an opening booked balance and a closing booked balance. Additional balance types may be present.

Balance Type CodeNamePresenceDescription
OPBDOpening BookedMandatoryThe booked balance at the start of the reporting period. Equivalent to the prior day's closing booked balance.
CLBDClosing BookedMandatoryThe booked balance at the end of the reporting period, reflecting all entries included in this statement.
CLAVClosing AvailableOptionalThe available balance at close, accounting for holds and pending items not yet booked.
ITBDInterim BookedOptionalA mid-period snapshot of the booked balance. Present when the statement covers multiple dates.
ITAVInterim AvailableOptionalA mid-period snapshot of the available balance.

Rules:

  • Bal.Amt must be a positive number. The sign of the balance is conveyed by Bal.CdtDbtInd (CRDT for a credit balance, DBIT for a debit/overdraft balance).
  • Bal.Dt must be present and must fall within the period covered by the statement.
  • The mathematical relationship OPBD + sum(Ntry.Amt for CRDT entries) − sum(Ntry.Amt for DBIT entries) = CLBD must hold.

2.4 Entries (Ntry)

Each Ntry represents one booked transaction on the account. An entry may group multiple underlying transactions into a single batch ; individual details are then available in the nested NtryDtls.TxDtls blocks.

XML TagNamePresenceRules
NtryRefEntry ReferenceOptionalA reference assigned by the bank.
AmtAmountMandatoryThe amount of the entry in the account currency. Must be a positive value.
CdtDbtIndCredit/Debit IndicatorMandatoryCRDT for credit entries (funds received); DBIT for debit entries (funds sent).
RvslIndReversal IndicatorOptionalSet to true if this entry is a reversal of a previously booked entry.
StsStatusMandatoryAlways BOOK in a camt.053 message. Entries in any other status are not included.
BookgDtBooking DateOptional (recommended)The date the entry was posted to the account (Dt sub-element, format YYYY-MM-DD).
ValDtValue DateOptional (recommended)The value date used for interest calculation. May differ from BookgDt (e.g. a Friday booking with a Monday value date).
AcctSvcrRefAccount Servicer ReferenceOptionalThe reference assigned to the entry by the account servicer. Useful for reconciliation and dispute resolution.
BkTxCdBank Transaction CodeMandatoryClassifies the entry using the ISO 20022 External Bank Transaction Code three-level hierarchy: Domn (Domain), Fmly (Family), and SubFmlyCd (Sub-Family). See table below.
AddtlNtryInfAdditional Entry InformationOptionalFree-text field for supplementary information about the entry. Maximum 500 characters.

Bank Transaction Code (BkTxCd) — common values:

DomainFamilySub-FamilyDescription
PMNTRCDTESCTReceived SEPA Credit Transfer
PMNTRCDTXBCTReceived cross-border credit transfer
PMNTICDTESCTIssued SEPA Credit Transfer
PMNTICDTXBCTIssued cross-border credit transfer
PMNTRDDTESDDReceived SEPA Direct Debit
PMNTIDDTESDDIssued SEPA Direct Debit
PMNTMCOPFEESFees and charges

2.5 Entry Details and Transaction Details (NtryDtls[#].TxDtls)

When an entry contains multiple underlying transactions (batch), a NtryDtls block is present for each transaction. Each NtryDtls contains one or more TxDtls sub-blocks providing transaction-level granularity.

XML TagNamePresenceRules
TxDtls.Refs.MsgIdOriginal Message IDOptionalThe MsgId of the original payment message (e.g. a pacs.008) that gave rise to this entry.
TxDtls.Refs.EndToEndIdEnd-to-End IdentificationOptionalThe end-to-end reference from the original payment instruction. Preserved unchanged through the payment chain.
TxDtls.Refs.UETRUnique End-to-End Transaction ReferenceOptionalThe UETR (UUID v4) assigned to the original payment, as defined in ISO 20022 and the SWIFT gpi standard.
TxDtls.Amt.InstdAmtInstructed AmountOptionalThe original instructed amount, which may differ from the entry amount if a currency conversion or fee deduction occurred.
TxDtls.CdtDbtIndCredit/Debit IndicatorMandatory (if TxDtls present)Must be consistent with the parent Ntry.CdtDbtInd.
TxDtls.RltdPtiesRelated PartiesOptionalIdentifies the debtor, creditor, ultimate debtor, and ultimate creditor involved in the underlying transaction.
TxDtls.RltdAgtsRelated AgentsOptionalIdentifies the debtor agent and creditor agent involved in the underlying transaction.
TxDtls.RmtInfRemittance InformationOptionalThe payment reference or structured remittance data (e.g. creditor reference, invoice number) included in the original payment. Provided as Ustrd (unstructured, free text, max 140 characters) or Strd (structured, per ISO 11649 or proprietary scheme).

Rules:

  • When NtryDtls.Btch is present (batch entry), the sum of all TxDtls.Amt values must equal the parent Ntry.Amt.
  • TxDtls.Refs.UETR is populated for all entries derived from ISO 20022 payment messages. It is absent for entries originating from legacy MT-format messages that did not carry a UETR.
  • RmtInf.Ustrd and RmtInf.Strd are mutually exclusive within a single TxDtls block.

3. Mambu Payments business rules

3.1 Account identification

3.2 Creation of balances

3.3 Creation of transactions