A fictional single-entry credit advice.
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 single-entry credit advice. SYNTHETIC / TRAINING ONLY; illustrative unvalidated.
crc32:a6674afcInitiation, serial and cover context, cancellation and correspondence, advices, and statements.
crc32:8b3a20e4Field correspondence, transformation treatment, and data-loss notes for Single credit advice compared with a structured bank-to-customer debit/credit notification.
crc32:baee9a30Curated field requirements, contexts, operational meaning, and implementation cautions.
crc32:d7a561d5{1:F01DEMOGB2LAXXX0000000000} {2:I910DEMODEFFXXXXN} {4: :13D:2607181200+0000 :50K:/DEMO-ORIGINATOR DEMO TRADING LTD :52A:DEMODEFFXXX :56A:DEMOUS33XXX -}
:20: Transaction Reference Number — mandatoryThe sender's unique reference for this confirmation.
References the advice itself, not the payment that caused the credit — that link lives in field 21.
:21: Related Reference — mandatoryThe reference of the transaction that produced the credit, as known to the sender.
This is what the account owner's reconciliation matches against expected receipts. Its usefulness depends entirely on what reference the crediting transaction carried.
⚠ If the underlying payment's reference was lost or replaced along the chain, the advice arrives but nothing matches.
:25a: Account Identification — mandatoryWhich account, held with the sender, was credited.
Option P adds the account owner's BIC alongside the account number for disambiguation.
:13D: Date/Time Indication — optionalWhen the credit was applied, with a timezone offset.
Valuable for intraday liquidity monitoring — without it the advice only tells you the value date, not when the funds actually became available.
:32A: Value Date / Currency / Amount — mandatoryThe value date, currency, and amount of the credit.
The amount is the credit as booked by the account servicer — after any of its charges — which is what reconciliation must match, not the amount the counterparty originally sent.
:50a: Ordering Customer — conditionalThe customer that originated the transaction which led to this credit, when there was one.
The standard requires ordering-party information on the advice — in practice at least one of 50a or 52a appears; the exact conditional rules are in the SWIFT Standards MT reference.
⚠ Sparse ordering-party data makes it hard to connect the credit to a business event without opening a query.
:52a: Ordering Institution — conditionalThe bank that ordered the transaction which produced the credit.
For bank-to-bank receipts (for example, an incoming MT202) this is usually the party shown; for customer payments 50a carries the originator instead.
:56a: Intermediary — optionalA bank the funds passed through on their way to the account servicer.
Useful when tracing where a payment's references or charges changed en route.
Share an operational observation or ask a concrete payments question. Your name and message are public; your email remains private.
Loading the discussion…