MT103, the customer payment

The MT103 is a single customer credit transfer message, and before the CBPR+ migration it was the most widely used cross border payment message in the world. It is sent by the debtor agent to the creditor agent, either directly or through intermediary banks, and it instructs the receiving bank to credit the beneficiary. The MT103 carries the debtor and creditor details, the amount and currency, the value date, the charges, and the remittance information that the beneficiary needs to reconcile the payment. It is used for supplier payments, salary payments, and any other payment where the originator is a customer rather than a bank. The MT103 has two main variants. The MT103 with STP, which stands for straight through processing, is used when the payment is fully automated and requires no manual repair. It has stricter validation on fields such as charges and remittance information. The standard MT103 allows more free text and is used when manual handling is expected. A bank that sends an MT103 must choose the correct variant and must populate the fields according to the SWIFT user handbook. A payment that is sent as an MT103 STP but contains free text that breaks the STP rules will be rejected or will lose its STP status and be processed manually. From a business perspective, the MT103 is the customer facing payment. The debtor sees the debit on their account, the creditor sees the credit, and the remittance information links the payment to the invoice. The charges field, field 71A, tells the receiving bank who bears the charges, and that choice affects the amount the beneficiary receives. A business analyst must understand the MT103 field structure, the mandatory versus optional fields, and the business meaning of each field, because those details determine whether the payment is processed automatically or falls into a repair queue. Follow a single MT103 through the happy flow. The customer instructs their bank, through online banking, a file upload, or a branch visit. The debtor agent validates the instruction, checks the account balance, screens the names, and debits the customer. It then builds the MT103 and sends it to the creditor agent, directly or through one or more intermediary banks. Each bank in the chain validates the message, checks its own sanctions lists, and passes it on. The creditor agent validates the beneficiary details and credits the beneficiary account. The customer sees the debit, the beneficiary sees the credit, and the remittance information links the payment to the invoice. The key fields each carry one part of that story. Field 20 is the transaction reference, up to 16 characters, assigned by the sender and used to track the payment. Field 23B is the bank operation code, which says what kind of transfer this is. Field 32A carries the value date, the currency, and the amount, with a comma as the decimal separator. Field 50a carries the ordering customer, field 59 carries the beneficiary, field 70 carries the remittance information in up to 140 characters, and field 71A carries the charges instruction. Field 71F shows the sender charges and field 71G shows the receiver charges, so the analyst can see exactly what was deducted and by whom. The charges field decides what the beneficiary actually receives. With OUR, the sender bears all charges and the beneficiary receives the full amount. With SHA, charges are shared, so the sending bank charges the sender and the receiving bank may charge the beneficiary. With BEN, the beneficiary bears all charges and the amount credited is reduced. An analyst who is asked why a supplier received less than the invoiced amount should look at field 71A first, then at fields 71F and 71G, because those fields show every deduction in the chain. Exceptions in the MT103 flow are handled with other MT messages. If a message fails validation, the network rejects it and the sender must fix the error and resend. If a payment was sent in error, the sender can ask for it back with an MT192 cancellation request. If a bank needs information about a payment, it sends an MT195 query and the other bank answers with an MT196. If none of those fit, banks use the MT199 free format message. A payment that cannot be applied, because the beneficiary account is closed or the details are wrong, is returned, and the return carries the original reference so the sender can match it to the first payment. Worked example with real numbers: a corporate in Lyon pays a supplier in Tokyo JPY 8,500,000 by MT103, and the payment carries field 70 with the invoice numbers, field 71A with SHA, and field 59 with the beneficiary account. The MT103 REMIT variant is different: it is used when the payment is a remittance, usually a low-value payment with remittance data, and it carries additional remittance information that a standard MT103 does not, so the beneficiary can reconcile it without a separate advice. MT103 REMIT is therefore a variant for remittance-heavy payments, not a different payment, and it is now legacy, because after 22 November 2025 new cross-border payments use pacs.008. Source: SWIFT MT103, MT103 STP and MT103 REMIT format specifications; SWIFT CBPR+ usage guidelines. Failure and recovery: an MT103 fails when the beneficiary account is closed, and the return comes as a pacs.004 in the ISO 20022 world, or as an MT103 return in the legacy world, with reason code AC04, and the sender must obtain the new account and resend. An MT103 REMIT fails when the remittance data is truncated, because the variant carried more data than the standard, and a bank that truncated it left the beneficiary unable to reconcile, so the recovery is a separate remittance advice, sent by email or by a camt.054 notification, and the beneficiary reconciles manually. A payment sent as REMIT after the migration date will be rejected, because the variant no longer governs new flows, and the sender must resend it as pacs.008, which is the correct remedy, not a second REMIT. For a business analyst, product owner or subject matter expert, the MT103 requirement must name the variant, standard, STP and REMIT, state when each was used, and state that REMIT and STP are legacy after 22 November 2025, so that a stakeholder who asks for a REMIT payment is told to use pacs.008 instead. The pacs.008 carries the remittance data in structured form, and the requirement must map field 70 to the pacs.008 remittance information, so the reconciliation that REMIT provided is preserved in the migration. A migration that loses the remittance data has lost the reason the payment was sent.