How 52a and 57a Change Across the Serial Chain

In the serial method, each bank in the chain sends a fresh MT103 to the next bank, deducts its own charge if the charge option allows it, and forwards the remaining amount. The first bank sends to the second, the second sends to the third, and the third credits the beneficiary. Field 20, the transaction reference, normally stays the same across the chain so every bank can link the legs together, while field 32A changes because the amount falls after each deduction. Field 50a, the ordering customer, also stays the same, because the customer who ordered the payment does not change as the money moves. Field 52a stays constant in meaning but changes in presence across the chain. On the first leg, if the sender is itself the ordering institution, field 52a is absent because the sender and the ordering institution are the same bank. On the second leg, the sender is an intermediary bank that did not take the original instruction, so field 52a must appear and must name the original ordering institution. On the third leg, field 52a still names that same original institution. The value does not change, but its presence does, and that presence tells each receiver that the sender is forwarding a payment ordered by someone else. Field 57a also stays constant in meaning but changes in presence in the opposite direction. On the first and second legs, field 57a names the final beneficiary bank, because the receiver of each early leg is not the bank that holds the beneficiary account. On the final leg, the receiver is the beneficiary bank itself, so field 57a disappears. The sender of the final leg knows that the receiver can credit the beneficiary directly, so naming the receiver again in field 57a would be redundant. A chain that keeps field 57a on the final leg is not invalid in every case, but it is sloppy and can confuse the receiving operations team. A worked chain makes the pattern concrete. BNP Paribas in Paris orders a payment of 367,574.90 dollars for its customer and sends the first MT103 to Wells Fargo in New York. BNP Paribas is the sender and the ordering institution, so field 52a is absent, and Banco Santander in Madrid is the account with institution, so field 57A reads BSCHESMM. Wells Fargo then sends the second MT103 to Bank of New York Mellon. Wells Fargo is now the sender, so field 52A appears with BNPAFRPP, and field 57A still reads BSCHESMM. Bank of New York Mellon then sends the third MT103 to Santander, where field 52A still reads BNPAFRPP and field 57a is gone. The practical lesson for operations teams is to check both fields on every leg before release. If field 52a is missing on a second leg, the next bank cannot see the true origin and may screen the wrong party. If field 57a is missing on an early leg, the receiver may not know where to forward the payment and may hold it. If field 57a is present on the final leg, the receiver should still credit the beneficiary, but it should query the sender to correct the practice. A payment of 95,000 euros from Hamburg to Tokyo that lost its field 52a at the second bank took four days to investigate, because the Tokyo bank could not prove the origin to its compliance team. Worked example with real numbers: the USD 367,574.90 payment from BNP Paribas Paris to Banco Santander Madrid travels as three MT103s, and field 56a and field 57a change at each leg. On the first leg, Paris to Wells Fargo, field 56A is Wells Fargo and field 57A is Bank of New York Mellon. On the second leg, Wells Fargo to Bank of New York Mellon, field 56A is no longer needed, because Wells Fargo is now the sender, and field 57A becomes the Madrid bank, because Bank of New York Mellon must forward to Madrid. On the third leg, Bank of New York Mellon to Madrid, both 56A and 57A disappear, because the payment has reached the beneficiary bank, and no further forwarding is needed. Source: SWIFT MT103 format specifications; Paiementor serial analysis. Failure and recovery: the chain fails when a bank forwards the payment without recalculating the fields, so the next bank receives a 56A naming a bank that has already been passed, and the payment loops back, or is held for investigation. The recovery is to stop the payment, recalculate the chain from the original instruction, and resend it with the correct fields for the remaining legs, but the recovery takes days, and the beneficiary is paid late. A bank that forwards MT103s without recalculating 52a, 56a and 57a will create loops, and the BA must require the recalculation to be tested with a three-leg worked example, where each leg is checked separately, because a test that checks only the first leg will miss the loop. For a business analyst, product owner or subject matter expert, the serial chain requirement must name the recalculation rule for each field at each hop, with a worked example showing the fields on each leg, and must state what happens when a field is wrong: the payment is held, returned or looped, and the recovery is a recalculation and a resend. The ISO 20022 pacs.008 carries the same chain in its agent fields, and the requirement must map each MT field to its pacs.008 equivalent, so the chain survives migration. A chain that is correct in MT but wrong in MX is a migration failure, and the test must cover all three legs.