A confirmation from the bank that keeps an account to the account owner that the account has been credited, with the reference of the incoming payment, value date, amount and originator.

The account servicing institution (for example a correspondent bank) sends it to the account owner or to a party the owner has authorised to receive it.

Why does an MT910 matter in cover payments?

The beneficiary’s bank gets the MT103 directly and the money separately through an MT202COV. The MT910 from its correspondent, quoting the MT103 reference in field 21, tells it the funds have arrived so it can pay its customer.

What is the difference between MT910 and MT900?

The MT910 confirms a credit and must name the originator (50a or 52a). The MT900 confirms a debit.

What is the ISO 20022 equivalent of MT910?

camt.054, Bank to Customer Debit Credit Notification, with the entry marked as a credit (CRDT).

Category 9: Cash management and customer status

MT910 Confirmation of Credit

Written and maintained by ZagTrader. Last reviewed 21 October 2026. How this page is sourced and checked

The MT910 is the message an account servicing institution sends to tell the account owner that it has credited the owner’s account, for example a correspondent confirming that funds for a cover payment have arrived on a bank’s nostro. It quotes the reference of the incoming payment, the account, value date, amount and who originated the funds. Its ISO 20022 equivalent is the credit notification in camt.054.

Message type: MT910
Category: 9
Structure: 9 fields listed
ISO 20022: camt.054

When MT910 is used

The sender is the institution that keeps the account and the receiver is the account owner, or a party the owner has authorised to receive the information. A concentrating institution can also send it on the owner’s behalf.

The MT910 matters most in the cover method. The beneficiary’s bank receives the MT103 directly, but the funds arrive on its account with its correspondent through an MT202COV. The correspondent’s MT910 tells the beneficiary’s bank that the cover has been credited, so it can release the payment to its customer.

For that matching to work, field 21 of the MT910 must carry the reference from the incoming message unchanged: field 20 of an MT103, or field 21 of an MT202, MT205, MT202COV or MT205COV. For a cover payment that means the beneficiary’s bank finds its own MT103 reference in the MT910.

Like the MT900, the MT910 is a confirmation and does not normally cause a booking at the receiver. The credit appears again on the statement (MT940 or MT950), and banks that send frequent statements often do not send MT910s.

MT910 format: sequences and fields

Message text (block 4)Mandatory

No sequences. Field 50a or field 52a must be present.

Tag	Name	Status	Format	Meaning
20	Transaction Reference Number	M	16x	The account servicer’s own reference for this confirmation. No leading or trailing slash and no double slash.
21	Related Reference	M	16x	The reference from the incoming message that caused the credit, copied unchanged: field 20 of an MT103, or field 21 of an MT202 or MT202COV. In a cover payment this is the MT103 reference of the beneficiary’s bank.
25	Account IdentificationOptions no letter or P	M	No letter: 35x P: 35x 4!a2!a2!c[3!c]	The account that was credited (the standard writes the tag as 25a: field 25 without a letter, or 25P). Option P adds the BIC of the account owner and is used only when the receiver is not the account owner.
13D	Date/Time Indication	O	6!n4!n1!x4!n	When the credit was posted: date (YYMMDD), local time (HHMM), sign and UTC offset.
32A	Value Date, Currency Code, Amount	M	6!n3!a15d	Value date, currency and amount credited, with a comma as the decimal mark. See how to read 32A.
50a	Ordering CustomerOptions A, F or K	C	A: [/34x] 4!a2!a2!c[3!c] F: 35x 4(1!n/33x) K: [/34x] 435x	The customer (or institution, when the credit comes from a category 1 payment) that originated the transaction behind the credit. Option F uses numbered lines as in the MT103.
52a	Ordering InstitutionOptions A or D	C	A: [/1!a][/34x] 4!a2!a2!c[3!c] D: [/1!a][/34x] 4*35x	The institution that originated the transaction behind the credit; when 50a is also present, the bank of that ordering customer. Option A is preferred; option D only when there is no BIC.
56a	IntermediaryOptions A or D	O	A: [/1!a][/34x] 4!a2!a2!c[3!c] D: [/1!a][/34x] 4*35x	The institution from which the account servicer received the funds, when that is useful to the account owner.
72	Sender to Receiver Information	O	6*35x	Additional information only, never instructions. Bilaterally agreed codes can be used in the structured `/8c/` form.

Format notation: n digits, a upper-case letters, c upper-case letters and digits, x any character of the Swift character set, d a decimal number with a comma, ! fixed length, [ ] optional, 4*35x up to 4 lines of 35 characters. M mandatory, O optional, C conditional (a rule decides).

Rules worth knowing

Either field 50a or field 52a must be present (network rule C1, error C06).
When a correspondent has received a cover payment and confirms the credit to the beneficiary’s bank, field 21 of the inward payment message is passed on unchanged in field 21 of the MT910.
Option P of field 25a is used only when the receiver is not the account owner.
In 50A, a financial institution BIC is allowed only if the credit came from a category 1 message that had a financial institution BIC in its 50A.
The MT910 does not normally lead to any booking by the receiver: it confirms a credit already made. The entry also appears on the next statement.

MT910 example

This continues the cover payment shown on the MT202COV page. ZAGTUS33XXX in New York holds BANKGB2LXXX’s USD account. It receives the USD 48,500.00 cover ordered by ZagTrader Test Bank, Dubai, credits BANKGB2L on 22 October 2026 and confirms the credit, quoting the MT103 reference ZT2610200057 so BANKGB2L can release the payment to its customer.

{1:F01ZAGTUS33AXXX0000000000}{2:I910BANKGB2LXXXXN}{4:
:20:C2610220007731
:21:ZT2610200057
:25:0087654321
:13D:2610221042-0400
:32A:261022USD48500,00
:52A:ZAGTAEADXXX
-}

Decode this example in the parser

Line by line

Line	What it says
{1:F01ZAGTUS33AXXX0000000000}{2:I910BANKGB2LXXXXN}{4:	Sender ZAGTUS33XXX (account servicer), input MT910 to BANKGB2LXXX (account owner).
:20:C2610220007731	ZAGTUS33’s reference for this confirmation.
:21:ZT2610200057	Field 21 of the incoming MT202COV, passed on unchanged: the reference of the MT103 that BANKGB2L received from ZagTrader.
:25:0087654321	BANKGB2L’s USD account with ZAGTUS33.
:13D:2610221042-0400	Posted at 10:42 New York time, UTC minus 4 hours.
:32A:261022USD48500,00	Value date, currency and amount credited.
:52A:ZAGTAEADXXX	Ordering institution: the bank that originated the payment. This satisfies the rule that 50a or 52a must be present.
-}	End of block 4.

BICs, account numbers and references are made up.

Common errors and rejects

Neither 50a nor 52a present (C06)
The network rejects an MT910 that names no originator. Add the ordering institution (52a) or, for a customer payment, the ordering customer (50a).
Field 21 changed by the correspondent
If the correspondent puts its own reference in field 21 instead of passing on the one it received, the beneficiary’s bank cannot match the cover to its MT103 and the customer waits. Ask for the reference to be passed unchanged, and match on amount, value date and UETR meanwhile.
How to fix it
MT103 received but no MT910 or credit
In the cover method the MT103 can arrive before the funds. Do not pay out until the cover is confirmed by MT910 or statement; if it does not arrive, query the ordering bank with an MT199 quoting the MT103 reference and UETR.
Credit confirmed but not on the statement
The entry should appear on the MT950 or MT940 for the value date. A missing or differently valued entry is a reconciliation break to raise with the account servicer.
How to fix it
Option F lines out of order in 50F (T54, T56, T73)
Numbered lines must start with 1/, be in numerical order and include a 3/ line with a valid ISO country code.

MT910 in ISO 20022

The ISO 20022 equivalent is camt.054 (Bank to Customer Debit Credit Notification) with an entry whose credit or debit indicator is CRDT. It can report the UETR, the end-to-end identification and the full debtor and creditor details of the underlying payment.

The November 2025 end of coexistence covered payment instructions, not reporting: MT9xx confirmations and statements continue to be supported on Swift, alongside the camt reporting messages. Public summaries of Swift’s CBPR+ roadmap say banks should be able to receive camt reporting messages by November 2027.

When the incoming payment was a pacs.008 or pacs.009, the MT910 fields are filled from ISO 20022 data, and long names or structured addresses may be shortened. See truncation in MX to MT translation.

MT910 questions

What is an MT910?: A confirmation from the bank that keeps an account to the account owner that the account has been credited, with the reference of the incoming payment, value date, amount and originator.
Who sends an MT910?: The account servicing institution (for example a correspondent bank) sends it to the account owner or to a party the owner has authorised to receive it.
Why does an MT910 matter in cover payments?: The beneficiary’s bank gets the MT103 directly and the money separately through an MT202COV. The MT910 from its correspondent, quoting the MT103 reference in field 21, tells it the funds have arrived so it can pay its customer.
What is the difference between MT910 and MT900?: The MT910 confirms a credit and must name the originator (50a or 52a). The MT900 confirms a debit.
What is the ISO 20022 equivalent of MT910?: camt.054, Bank to Customer Debit Credit Notification, with the entry marked as a credit (CRDT).

All MT messages · Category 9 messages · ISO 20022 messages · Codes · Troubleshooting