GLOBAL PAYMENTS KNOWLEDGEISO 20022 / SWIFT / SEPA / MT / MX
PAYMENTSSIGNAL

The interactive academy for the standards, messages, and rails that move money.

GET IN TOUCH
06 / SWIFT & MT10 MIN

MT9xx: confirmations and statements

MT910 confirmations and MT940 statements tell a bank what happened on its accounts at other banks — the raw material of reconciliation.

Contributor Shubham Mathure

NOT STARTED

L0 Explain simply

An everyday analogy: think of the accounts your bank holds at other banks as your own current account, just one step removed. MT9xx messages are the alerts and statements for those accounts. An MT910 is the push notification: "money just arrived on your account with us". An MT940 is the statement: every movement on the account, line by line, usually delivered at the end of the day. And just as you check your statement against the payments you expected, banks check these messages against every transfer they sent and every credit they were promised. That checking — finding the entries that match and chasing the ones that do not — is reconciliation, and it is a full-time job at scale.

L1 Core concepts

Category 9 MT messages carry cash management information rather than payment instructions. The MT910, confirmation of credit, is sent by the bank that services an account to the bank that owns it, advising that a specific credit has been booked — often within moments of the booking. The MT940, customer statement message, reports an account's activity as a formal statement: opening balance, a line for every entry, closing balance, typically produced once per business day. Together they let a bank see what actually happened on its nostro accounts around the world, as opposed to what its own systems expected to happen. Related types exist in the same family — including a debit confirmation and other statement variants — but MT910 and MT940 are the two this topic focuses on.

L2 Practitioner view

Practitioners consume MT9xx in two rhythms. Intraday, MT910s drive time-sensitive decisions: releasing a customer credit, confirming that expected cover for a payment has arrived, or feeding dashboards that track how much liquidity sits on each nostro right now. End of day, MT940s feed the reconciliation engines: every statement line is matched against the entries the bank's own ledgers expected — an outgoing MT103 here, an incoming cover there. Whatever fails to match becomes a break, parked in investigation queues or a suspense account until explained. The quality problems are mundane but constant: statements arriving late, references truncated or reformatted by the servicing bank so automatic matching fails, and duplicated lines after a resend. How far banks automate this varies widely between institutions.

L3 Technical details

An MT940 carries :20: reference, :25: the account identification, :28C: statement and sequence number, :60a: opening balance, a repeating :61: statement line, and :62a: closing balance. Each :61: line packs the value date, entry date, a debit or credit mark, the amount, a transaction type code, and the servicing bank's reference, with an optional :86: field carrying free-format detail for the account owner. Options on the balance fields (F final, M intermediate) distinguish complete statements from partial ones. An MT910 carries :20:, :21: the related reference, :25: the account, and :32A: value date, currency, and amount, plus ordering party details. Full formats and validation rules are in the SWIFT Standards MT Category 9 documentation on swift.com, which requires a SWIFT user account.

Sources & standards1
  1. Official requirement

    Swift Standards MT (annual standards releases) ↗ — Swift · Category 9 — MT910, MT940

    Defines the MT message standards (including MT101, MT103, MT202/202 COV, and the MT9xx statement messages) exchanged over the Swift FIN network, maintained through annual standards releases. · Checked 2026-07-12

    Full field-level specifications live in the Swift Knowledge Centre User Handbook behind a swift.com login; content here relies on public summaries. Swift ended MT-to-ISO 20022 coexistence for in-scope cross-border payment instructions (for example MT103 and MT202) in November 2025; MT statement messages are being phased out on a separate timeline.

SEE THE PAYMENT MOVE

Corporate payment — legacy MT lifecycle — swimlane diagramThe legacy MT path from MT101 and MT103 through cancellation, investigations, returns, confirmations, and statements — with explicit no-equivalent and migration notes. The full step-by-step description follows this diagram as text.
MESSAGECLEARING OBLIGATIONSETTLEMENTPOSTING
Corporate payment — legacy MT lifecycle. A legacy teaching composite, not a recommendation to start new MT implementations. It joins corporate initiation, serial correspondent settlement, investigations, returns, and two account-reporting perspectives; bilateral services and migration dates vary. PLAY IT STEP BY STEP →
Read the steps as text
  1. 01Message
    Treasury sends a request for transferAsha Traders treasury → Bank Alfa (ordering bank) · MT101

    Asha Traders asks Bank Alfa to execute the supplier payment with an MT101. It is the legacy initiation request, not the bank-to-bank customer payment and not proof of execution.

  2. 02Processing
    Bank Alfa validates the MT101Bank Alfa (ordering bank)

    The bank checks the mandate, message fields, funds, cut-off, routing, and sanctions-screening results. A FIN ACK only confirms network acceptance; pain.002-style business status has no MT equivalent.

  3. 03Posting
    Bank Alfa debits Asha TradersBank Alfa (ordering bank)

    Once it accepts the request for execution, Bank Alfa books the customer debit under the account agreement before it releases the interbank MT103.

    • DR Asha Traders USD operating account — USD 125,000.00
  4. 04Message
    Treasury receives a debit confirmationBank Alfa (ordering bank) → Asha Traders treasury · MT900

    Where contracted, MT900 confirms one booked debit on the serviced account. It is an account-entry advice, not a beneficiary-credit confirmation and not a substitute for payment status.

  5. 05Message
    Bank Alfa sends the customer paymentBank Alfa (ordering bank) → Meridian Bank (correspondent) · MT103

    The MT103 carries the customer-payment instruction into the correspondent chain. In a serial route the instruction follows the account path used to settle the value.

  6. 06Processing
    Meridian validates and screens the MT103Meridian Bank (correspondent)

    The correspondent validates FIN fields, checks Bank Alfa's account, screens the parties and narrative data, and decides whether it can book and forward the payment.

  7. 07Settlement
    Meridian settles across its booksMeridian Bank (correspondent)

    Meridian debits Bank Alfa's USD account and credits Nordbank's USD account. The ledger movement is the settlement; the MT103 is the instruction.

    • DR Bank Alfa USD account at Meridian — USD 125,000.00
    • CR Nordbank USD account at Meridian — USD 125,000.00
  8. 08Message
    Nordbank receives a credit confirmationMeridian Bank (correspondent) → Nordbank (beneficiary bank) · MT910

    The MT910 advises Nordbank that its account at Meridian was credited. Nordbank uses it to match the incoming value against the customer-payment instruction.

  9. 09Message
    The MT103 reaches NordbankMeridian Bank (correspondent) → Nordbank (beneficiary bank) · MT103

    Meridian forwards the serial customer-payment message with the original references and party details so Nordbank can validate and apply the credit.

  10. 10Processing
    Nordbank validates and matches the paymentNordbank (beneficiary bank)

    Nordbank checks the beneficiary account, screens the payment, and matches the instruction to the credited nostro entry before paying its customer.

  11. 11Posting
    Nordbank credits the supplierNordbank (beneficiary bank)

    Nordbank books the credit to Northstar Components. A later cancellation is now a recovery request; the original credit cannot be erased by sending another message.

    • CR Northstar Components USD account — USD 125,000.00
  12. 12Message
    Treasury receives an intraday balance reportBank Alfa (ordering bank) → Asha Traders treasury · MT941

    Where contracted, MT941 reports balances without the full transaction list. It is one legacy predecessor of the broader camt.052 account report.

  13. 13Message
    Treasury receives intraday transactionsBank Alfa (ordering bank) → Asha Traders treasury · MT942

    MT942 reports account movements during the day. Treasury uses the original and account-servicer references to match the payment before the final statement arrives.

  14. 14Message
    The customer statement closes the dayBank Alfa (ordering bank) → Asha Traders treasury · MT940

    Bank Alfa sends the booked customer statement. Asha reconciles the MT940 entry to the original MT101 transaction and its own expected cash position.

  15. 15Message
    Bank Alfa reconciles its nostro statementMeridian Bank (correspondent) → Bank Alfa (ordering bank) · MT950

    Meridian's MT950 reports the entries on Bank Alfa's correspondent account. This bank-to-bank reconciliation is a different account perspective from the corporate's MT940.

MESSAGES INVOLVED

Sources for this topic2
  1. Official requirement

    Swift Standards MT (annual standards releases) ↗ — Swift · Category 9 — MT910, MT940

    Defines the MT message standards (including MT101, MT103, MT202/202 COV, and the MT9xx statement messages) exchanged over the Swift FIN network, maintained through annual standards releases. · Checked 2026-07-12

    Full field-level specifications live in the Swift Knowledge Centre User Handbook behind a swift.com login; content here relies on public summaries. Swift ended MT-to-ISO 20022 coexistence for in-scope cross-border payment instructions (for example MT103 and MT202) in November 2025; MT statement messages are being phased out on a separate timeline.

  2. Simplified educational illustration

    Payments Signal editorial teaching models — Payments Signal

    This site's own simplified teaching models. · Checked 2026-07-12

    What this simplifies: The alert-and-statement analogy compresses category 9: statement processing in practice involves per-bank formatting dialects, and interim statements and debit confirmations are only mentioned, not covered.

    Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.

Deepest material on this page: L3 — Technical details. Where a topic stops short of implementation depth, that is a deliberate coverage decision, not an oversight — see coverage.