A fictional end-of-day account statement.
Illustrative, non-production example. Values are fictional and the message is not validated for any specific network, scheme, or implementation guide.
EVIDENCE AT ARM'S REACH
Download the canonical fictional sample, then open the exact official definition and profile needed for implementation testing.
An XSD checks XML structure. A usage guideline adds profile rules, conditional fields, code restrictions, and business controls. XSD-valid does not mean scheme-compliant.
The annual MT standard and release information. Full field specifications may require an authenticated Swift account.
A fictional end-of-day account statement. SYNTHETIC / TRAINING ONLY; illustrative unvalidated.
crc32:08d809ddInitiation, serial and cover context, cancellation and correspondence, advices, and statements.
crc32:8b3a20e4Field correspondence, transformation treatment, and data-loss notes for Customer statement migration from compact FIN lines to structured ISO 20022 entries.
crc32:6bcf9eecCurated field requirements, contexts, operational meaning, and implementation cautions.
crc32:ee953655{1:F01DEMOGB2LAXXX0000000000} {2:I940DEMODEFFXXXXN} {4: :21:NONREF :61:2607180718D1250,00NTRFDEMOE2E001//DEMOREF001 :86:DEMO INVOICE 1001 :64:C260718EUR48750,00 -}
:20: Transaction Reference Number — mandatoryThe sender's unique reference for this statement message.
Identifies the message, not the account or period — those live in fields 25a and 28C.
:21: Related Reference — optionalLinks the statement to a request, when it was produced in answer to one.
Used when the statement responds to an MT920 request; routine scheduled statements omit it.
:25a: Account Identification — mandatoryWhich account the statement describes.
The identifier is the servicer's account number, which may differ from how the owner labels the same account internally — mapping tables matter.
:28C: Statement Number / Sequence Number — mandatoryNumbers the statement, and the page when one statement spans several messages.
Continuity checking on statement and sequence numbers is how reconciliation systems detect missing statements or pages.
⚠ Processing pages out of order, or missing one, corrupts the running balance chain.
:60a: Opening Balance — mandatoryThe balance the statement starts from — debit or credit, date, currency, and amount.
Option F opens a statement; option M continues from a previous page. The opening balance should equal the previous statement's closing balance.
⚠ Booking a statement without checking it chains onto the prior closing balance lets gaps slip through unnoticed.
:61: Statement Line — optionalOne booked entry: value date, debit or credit, amount, transaction type, and references.
Repeats for each entry. The subfields — especially the customer and bank references — are where auto-matching succeeds or fails, and banks differ in what they put there.
⚠ Parsers that assume one bank's 61 conventions break on the next bank's statements; references truncated upstream arrive here unmatchable.
:86: Information to Account Owner — conditionalFree-form detail about the entry above it — counterparty, remittance text, charge details.
The structure inside 86 is not standardised across banks: many use national or proprietary code conventions. Treat each account servicer's format as its own parsing profile.
⚠ Assuming a single 86 layout across correspondents is one of the most common causes of broken automated reconciliation.
:62a: Closing Balance (Booked Funds) — mandatoryThe balance after all entries in the statement.
Option F closes the statement, option M carries an intermediate balance to the next page. Opening balance plus entries must equal this figure.
⚠ A closing balance that does not compute from opening balance plus lines means entries are missing or duplicated somewhere.
:64: Closing Available Balance — optionalHow much of the closing balance is actually available, once uncleared items are excluded.
Liquidity teams care about the difference between booked and available; not every servicer supplies it.
Share an operational observation or ask a concrete payments question. Your name and message are public; your email remains private.
Loading the discussion…