What MT101 Is and When Corporations Use It

MT101 is a SWIFT message type called Request for Transfer. It is a customer to bank instruction, sent by a corporate customer to its account servicing bank, asking the bank to debit a specified account and to execute one or more payment transactions. The customer is usually a corporation with a treasury operation, and the bank is the account holding bank that carries out the payments. A treasurer at a multinational company may send an MT101 to HSBC in London, instructing it to pay 40 suppliers in five countries from the company operating account. The bank receives the message, validates it, and executes each transaction in turn. MT101 sits in SWIFT message category 1, customer payments and cheques, and it is one of the few category 1 messages that a corporate customer sends directly rather than a bank sending it on the customer behalf. Corporations use MT101 for bulk and repetitive payments, where sending each payment as a separate instruction would be slow and costly. A payroll file for 2,000 employees, a supplier payment run for 300 invoices, or a monthly rent payment for 50 offices can all be sent as one MT101 with many transactions. Each transaction inside the message carries its own beneficiary, amount, currency, and value date, so the bank can process them as a batch while keeping each payment separate in its own records. The corporation saves time, reduces manual entry errors, and gets one consolidated instruction instead of hundreds of individual ones. The bank charges a lower fee per transaction in a bulk MT101 than for individually instructed payments, because the processing is automated end to end. MT101 is also used for cross border payments that need a structured instruction. A company in Amsterdam may use MT101 to pay a supplier in Tokyo in Japanese yen, a consultant in New York in United States dollars, and a landlord in Paris in euros, all from one message to its Dutch bank. The bank will use its correspondent network or a payment system to deliver each payment, and it will report the result for each transaction separately. The corporation can therefore manage a global payment run from one treasury workstation and one bank relationship. The bank decides the routing for each transaction, using its own payment hub, and the corporation does not need to know which correspondent or clearing system each leg uses. Before a corporation can send MT101, it needs a SWIFT relationship with its bank. The corporation either holds its own BIC and connects to SWIFTNet through the SCORE or MA-CUG closed user group, or it sends the message through a service bureau or a treasury management system that holds the SWIFT connection. In both cases a Relationship Management Application, RMA, must exist between the sender BIC and the receiver BIC, authorising the MT101 message type. Without an RMA, the SWIFT network will reject the message. The corporation and the bank also sign a bilateral agreement covering cut-off times, the maximum number of transactions per message, the handling of rejected transactions, and the format of the status reporting back to the customer. MT101 is a customer to bank message, not a bank to bank message. It starts with the customer, and the bank acts on it as the customer agent. That is the key difference from MT103, which is a bank to bank customer payment instruction sent by the ordering bank to the beneficiary bank. An MT101 is the input that causes the bank to create one or more MT103 or pacs.008 messages downstream. A treasurer who understands this distinction knows that the MT101 is where the instruction is born, and the MT103 is where the bank to bank leg begins. The MT101 also differs from a pain.001 file, which is the ISO 20022 equivalent. A pain.001 carries the same idea, a customer payment initiation, but in XML format with a richer structure, and it is used on domestic and SEPA channels rather than over SWIFT. A corporation chooses MT101 when it wants a SWIFT standard message, when it has many transactions to send at once, or when its treasury system is built around SWIFT. A single urgent high value payment is often sent as a direct instruction through online banking instead, and a domestic bulk file may be sent as a pain.001 file in ISO 20022 format. MT101 is chosen for a weekly supplier run, a monthly payroll, or a regular repatriation of funds from subsidiaries. The treasurer picks the tool for the job, and MT101 is the tool for a structured, multi-transaction, cross border payment run sent over SWIFT. An SME must also know the limits. An MT101 has a maximum size, and a bank will set its own limit on the number of Sequence B blocks, often between 100 and 500 transactions per message. The requested execution date in field 30 must be a valid banking day for the debit account currency, and the bank will reject the message if the date is in the past or on a non-business day. If one transaction fails validation, the bank may reject that transaction and process the rest, or it may reject the whole message, depending on the bilateral agreement. The bank reports the outcome per transaction, usually with an MT199 free format message or through an account statement, so the treasurer can see exactly which payments executed and which did not. Worked example with real numbers: a corporate in Frankfurt has 200 supplier payments to make on Friday, totalling EUR 1.8 million, and it sends one MT101 to its bank, instructing the bank to make all 200 payments, debiting the corporate account for EUR 1. The chaining is the point: the MT101 is the instruction, the MT103 is the customer payment, and the MT202 COV is the cover, and the three must be linked, because the corporate must be able to trace its EUR 1.8 million from the MT101 to the 200 MT103s and to the 40 covers, and the bank must be able to prove that every MT103 has a cover where one is needed. Source: SWIFT MT101 format specifications; Paiementor articles on MT101 chaining. Failure and recovery: the chaining fails when the bank creates the MT103s but not the covers, because the cross-border MT103s arrive at the beneficiary banks without funds, and the beneficiary banks hold them, and the suppliers are not paid. The recovery is to create the missing covers, send them, and to check that every MT103 that needs a cover has one, by matching the MT101 to the MT103s and to the covers, but the recovery takes a day, and the suppliers are paid late. A bank that processes MT101s without a chaining check will create this failure, and the BA must require a reconciliation that matches the MT101 total to the MT103 total and to the cover total, before the payments are released, because a mismatch found after release is a payment that has already failed. For a business analyst, product owner or subject matter expert, the MT101 requirement must name the chaining, MT101 to MT103 plus MT202 COV, the linking references, the reconciliation, and the handling when a cover is missing. In ISO 20022 the MT101 becomes a pain.001, the MT103 becomes a pacs.008, and the MT202 COV becomes a pacs.009 COV, and the requirement must map each MT message to its MX equivalent, and must state that the chaining survives migration, because a pain.001 that creates pacs.008s without pacs.009 COVs is the same failure in a new format. A chaining that is not tested is a chaining that will fail in production.