Field 50a Ordering Customer in Sequence A vs Sequence B

Field 50a in Sequence A names the ordering customer for the whole MT101 message. It identifies the party that instructs the bank to execute the payments in the message. In most cases this is the account holder, the corporation that owns the debit account. A message from a company called Meridian Foods Ltd, with account GB29 HBUK 4012 3456 7890 01 at HSBC, will carry field 50K in Sequence A with the name Meridian Foods Ltd and its address in Birmingham. The bank uses this field to check that the sender is authorised to instruct payments from that account, and to apply sanctions screening against the ordering customer. Field 50a in Sequence B names the ordering customer for that single transaction. In a simple payment run, it is usually the same as Sequence A, and it may be omitted or repeated for clarity. The difference matters when the transaction is paid on behalf of another party, such as a subsidiary, or when the debit account belongs to a different entity. A parent company may send an MT101 where Sequence A names the parent, but a Sequence B for a payment from a subsidiary account names the subsidiary as the ordering customer for that transaction, so that the beneficiary and the reporting show the correct party. The bank will check that the subsidiary is authorised to use the debit account, or that the parent has a mandate to pay on its behalf. Field 50 can appear with three options, called 50A, 50F, and 50K. Option A carries a BIC, format 4!a2!a2!c[3!c], such as MERIGB22, and is used when the ordering customer is a financial institution or a corporate with a BIC. Option F carries structured party identification, with a party identifier on the first line, for example /12345678, followed by the name and address in coded subfields, and it is used when the bank needs a precise identification for regulatory reporting. Option K carries free text name and address, format 4*35x, and is the most common option for a corporate ordering customer, because it is simple to complete and easy to read. The choice of option is a business decision, and it affects how the bank screens and reports the payment. Option F deserves attention because it is the option that carries structured data. The first line is the party identifier, which may be an account number or a national identifier, prefixed by a slash. The following lines carry the name and address, and the last line may carry the country and town. A 50F for a German company might read /DE123456789, followed by Atlas GmbH, followed by the street and town, followed by DE. The bank can parse this structure into its screening and reporting systems without manual reading. Option K, by contrast, is free text, and the bank must rely on the name matching its customer record. An SME who designs a payment interface should prefer 50F where the data is available, because it reduces screening false positives and improves the quality of the regulatory reporting. The bank uses field 50a to check authorisation, to apply sanctions screening, and to report the payment. If the Sequence A 50a names a company that is not the account holder, the bank will query the instruction, because it cannot debit an account on the instruction of a third party without a mandate. If the Sequence B 50a names a subsidiary, the bank will check that the subsidiary is authorised to use the debit account, or that the parent has a mandate to pay on its behalf. A mismatch that is not explained by a mandate will cause a delay or a rejection. The bank also screens the 50a name against sanctions lists, and a name that matches a sanctioned entity will stop the whole message until the compliance team clears it. A practical example makes the rule clear. A group treasurer at a company called Atlas Holdings sends an MT101 to Barclays to pay a supplier in Frankfurt for 60,000 euros. Sequence A field 50K names Atlas Holdings Ltd, London, and field 25 names the Atlas group account. Sequence B for that payment also names Atlas Holdings Ltd, because Atlas is paying its own supplier. In a second payment in the same message, Atlas pays a supplier for its German subsidiary, Atlas GmbH. Sequence B field 50K names Atlas GmbH, Munich, and field 25 names the Atlas GmbH account in Frankfurt. The bank can now report each payment under the correct ordering customer, and the beneficiary sees who really ordered the payment. The two Sequence B blocks in one message therefore carry different ordering customers, and the bank handles each correctly. The ISO 20022 equivalent of field 50a is the Dbtr element in a pain.001. In pain.001, the debtor is carried as a structured party with name, postal address, and identification, which is closer to option F than to option K. When a bank converts an MT101 into a pain.001, or when a corporate migrates from MT101 to pain.001, the 50K free text must be parsed into the structured Dbtr fields, and that parsing is a common source of mapping errors. A business analyst who writes the mapping must specify how each line of the 50K is split into name and address, and what happens when the 50K contains more lines than the pain.001 structure can hold. Common errors in field 50a are worth knowing. The most common is omitting 50a in Sequence B when the transaction is paid from a different account, which leaves the bank unable to identify the ordering customer for that payment. Another is using option A with a BIC that does not belong to the ordering customer. A third is putting the account number in 50a instead of in field 25, which confuses the bank validation. A fourth is a 50K with more than four lines, which breaks the network validated rule and causes the whole message to be rejected by SWIFT. An SME who reviews an MT101 interface should check that the system enforces the four line limit on 50K, that it requires 50a in Sequence B whenever field 25 in Sequence B differs from Sequence A, and that it validates the BIC format when option A is used.