Funds Repatriation and a Full Worked Example

Funds repatriation is the movement of surplus cash from a subsidiary back to the parent, and MT101 is a common way to instruct it. A subsidiary in Germany has 500,000 euros in its operating account that it does not need for the next quarter. The parent in London wants the funds in its pounds account. The group treasurer sends an MT101 to the subsidiary bank, instructing it to debit the subsidiary euros account and to pay 500,000 euros to the parent account in London. The payment is a normal MT101 transaction, but the purpose is repatriation, and the treasury, tax, and regulatory considerations are different from a supplier payment. The repatriation may be a dividend, a repayment of an intercompany loan, or a return of surplus cash under a cash pooling arrangement. The distinction matters for the tax treatment and for the reporting. A dividend is a distribution of profit, and it may attract withholding tax in the subsidiary country. A loan repayment is a return of principal, and it may be tax free but must be documented as a loan. A cash pooling movement is a transfer within a pooling structure, and it is governed by the pooling agreement. The MT101 field 70 remittance information should state the purpose, for example DIVIDEND 2025 or LOAN REPAYMENT, so that the bank and the tax authorities can classify the payment correctly. A remittance information field that only says PAYMENT is not enough for a repatriation. The foreign exchange conversion is part of the repatriation. The subsidiary account is in euros, and the parent account is in pounds. The bank will convert the 500,000 euros at its rate, and the parent will receive the pounds equivalent, less any conversion spread and charges. The MT101 may carry field 33B, the currency and amount originally instructed, and field 36, the exchange rate, if the rate is agreed in advance. If the rate is not agreed, the bank applies its rate on the execution date, and the parent receives whatever the rate produces. A treasurer who repatriates a large amount should agree the rate in advance, or use a foreign exchange contract, because a movement in the rate between the instruction and the execution can change the amount received by thousands of pounds. Here is a full worked example that brings the whole chapter together. Atlas Holdings, London, sends an MT101 to Barclays on 12 May 2026, reference PAYRUN 2026 0512, execution date 120526. Sequence A field 50K names Atlas Holdings Ltd, London. Field 25 names the Atlas pounds account GB29 BARC 2012 3456 7890 01. The message has four Sequence B blocks, indexed 1/4, 2/4, 3/4, 4/4 in field 28D. Sequence B 1 pays 45,000 euros to a supplier in Berlin, field 32B EUR45000,00, field 59a naming the supplier and its IBAN DE89 3704 0044 0532 0130 00, field 70 naming the invoice number INV 2026 0441, field 25 naming the Atlas euros account. Sequence B 2 pays 12,000 pounds to a consultant in Manchester, field 32B GBP12000,00, field 59a naming the consultant and its account, field 70 naming the engagement reference. Sequence B 3 pays 30,000 dollars to a supplier in New York, field 32B USD30000,00, field 59a naming the supplier, field 70 naming the purchase order. Sequence B 4 is a funds repatriation, paying 500,000 euros from the Atlas GmbH account in Frankfurt to the parent pounds account, field 32B EUR500000,00, field 50a naming Atlas GmbH, field 25 naming the Atlas GmbH account, field 70 stating LOAN REPAYMENT ATLAS GMBH TO ATLAS HOLDINGS. The bank processes the four transactions. It debits the euros account for 45,000 euros and for 500,000 euros, the pounds account for 12,000 pounds, and the dollars account for 30,000 dollars. It converts the repatriation at the agreed rate, and it credits the parent pounds account with the converted amount. It sends the supplier payments through the appropriate routes, and it reports each transaction separately in the status report. The treasurer reconciles the four statement entries against the four field 21 references, and confirms that the repatriation arrived and that the three supplier payments were executed. The whole run, four payments in three currencies from three accounts, was instructed in one MT101. The ISO 20022 equivalent of this MT101 is a pain.001 file. The pain.001 carries a group header, one payment information block per debit account, and one credit transfer transaction information block per payment. The MT101 Sequence A maps to the pain.001 group header and payment information, and each Sequence B maps to a credit transfer transaction information block. Field 50a maps to the debtor, field 59a maps to the creditor, field 32B maps to the instructed amount, field 70 maps to the remittance information, and field 71A maps to the charge bearer. A bank that migrates a corporate from MT101 to pain.001 must map each field, and must handle the cases where the MT101 carries a field that the pain.001 structure does not have, or where the pain.001 requires a field that the MT101 did not carry. The mapping is a project in itself, and it is covered in depth in the ISO 20022 chapters of this course. An SME should remember three things about MT101. First, it is a container, and each Sequence B is a separate payment with its own ordering customer, debit account, amount, and reporting. Second, the field 50a and field 25 in Sequence B are the controls that make multi-account and subsidiary payments work, and they must be used explicitly. Third, the reconciliation is per transaction, and a treasury system that cannot reconcile at transaction level cannot use MT101 safely. A business analyst who can explain these three points, with the field numbers and a worked example, can design an MT101 interface that a treasurer will trust. Worked example with real numbers: a corporate in Singapore repatriates USD 3,000,000 of funds from its subsidiary in London, and it sends one MT101 instructing its bank to collect USD 3,000,000 from London and credit Singapore. The bank creates an MT103 for USD 3,000,000 from London to Singapore, it also creates an MT202 COV for USD 3,000,000 through its correspondent in New York. The MT101 total is USD 3,000,000, the MT103 total is USD 3,000,000, and the MT202 COV total is USD 3,000,000, and the three must match, because a mismatch means a payment is missing or a cover is missing. The funds arrive in Singapore in two days, and the corporate uses them to pay a dividend, so the repatriation is complete, and the chaining is proven by the matching totals. Failure and recovery: the repatriation fails when the MT202 COV is sent through a correspondent that does not hold an account for the Singapore bank, so the cover is returned, and the MT103 arrives in Singapore without funds, and the Singapore bank holds it. The recovery is to send the cover through a different correspondent, one that holds the Singapore account, and to resend the MT103 if it was returned, but the dividend is delayed by three days, and the corporate must explain the delay to its shareholders. A repatriation that is not tested for the cover route will fail, and the BA must require the cover route to be validated before the MT101 is accepted, because a repatriation that cannot settle is a repatriation that should not have been instructed. For a business analyst, product owner or subject matter expert, the repatriation requirement must name the chaining, the matching totals, the cover route validation, and the handling when the cover is returned. The ISO 20022 equivalent is a pain.001 that creates a pacs.008 and a pacs.009 COV, and the requirement must state that the totals must match in MX as they did in MT, and that the cover route must be validated in MX as it was in MT. A repatriation that is tested only in MT and not in MX is a repatriation that will fail after migration, and the test must cover both.