Use a SWIFT MT103 to trace a delayed wire by taking Field 20 as the trace reference, verifying Fields 32A, 50, 59, and 71A against your invoice and bank details, and asking the sending or receiving bank's wire team to trace the payment. The MT103 shows the instruction was sent, not that funds were credited, so wait for beneficiary-bank confirmation before marking the invoice paid.
Start with Field 20, then verify the core details before you contact support. That gives your bank a usable trace anchor and helps you avoid delays caused by mismatched payment data.
Before you escalate, run this quick self-audit:
Field 71A matches the charge instruction agreed with the client.Field 20 sender reference, and the UETR if the sender provides it.Field 20 is the sender's reference. Use the exact value from the MT103, not an invoice number, screenshot label, or batch ID. If this reference is missing or wrong, your bank may need additional manual checks to trace the payment.
Ask your bank: "Please trace this payment using Tag 20 (sender's reference) and check whether any bank in the chain has it on hold." If available, provide the UETR as a separate identifier.
This is a common source of avoidable delays. Field 50 is the ordering customer, and Field 59 is the beneficiary customer. Compare the name, account number or IBAN, and beneficiary lines on the MT103 against the exact details you gave the client.
Mismatches here can trigger repair handling or other delays. Incorrect or incomplete data can lead to failed or defective execution, and some bank formats explicitly require a valid IBAN and beneficiary name. Ask your bank: "Please confirm whether Field 59 was repaired or held due to beneficiary-data mismatch, and whether beneficiary details match the MT103."
Field 71A is the charge instruction. It sets the intended fee allocation, but intermediary handling can still affect the final amount you receive.
| 71A code | Expected payout impact | Common reconciliation confusion |
|---|---|---|
BEN | Charges can be deducted from the transfer, so the amount received may be lower | Client says they sent the full invoice amount, but your deposit is short |
SHA | Net receipt can still vary based on how fees are applied along the route | Outgoing amount matches invoice, net received does not |
OUR | Charge details may still need reconciliation against message fields (for example 71G with 32A context) | Client assumes OUR guarantees exact receipt in every corridor |
If the amount is short, ask whether sender or receiver charge details tied to 71A explain the gap before you treat it as an error.
Field 32A contains the value date, currency code, and amount. Verify all three against your invoice and payment advice.
| 32A part | Verify against |
|---|---|
| Value date | Invoice and payment advice |
| Currency code | Invoice and payment advice |
| Amount | Invoice and payment advice |
If any element is off, you may be dealing with an instruction issue, internal review, intermediary handling, or a compliance hold.
Ask your bank: "Please confirm Tag 32A (value date, currency, amount) and whether the payment is pending internal review, intermediary handling, or compliance review." Send one evidence pack with the MT103, the invoice, the exact beneficiary details, and Field 20.
Related: The Impact of EU Blacklisting on Offshore Jurisdictions.
Short answer: no. Treat an MT103 as proof that a payment instruction entered the SWIFT process, not proof that funds were credited and made available in your account.
Some providers describe an MT103 as a proof-of-payment document, and that can be useful for sender-side records. For operations, the safer standard is stricter. It shows instruction and routing progress, but final receipt still requires beneficiary-side credit confirmation.
A payment can be accepted at the network level and still be held, sent back for additional information, rejected, or returned before credit. It can also show an intended value date without confirming the exact posting time at your bank.
If cash timing matters, do not mark the invoice paid until your bank confirms credit. That distinction matters because your next move depends on what the document actually proves.
MT103 includes the core routing and check data: ordering customer, beneficiary, amount, currency, and value date. If details do not align, banks may hold, request more information, reject, or return the transfer. Next action: ask your bank's wire team whether the transfer is pending verification or additional information.
A correctly sent instruction can still pause during intermediary or receiving-bank review. Next action: ask whether the payment is under review and whether the sender must provide anything through their bank.
Wires can move through intermediary banks, and delays or returns can happen at those handoffs. Next action: ask the sender to request a formal trace, and ask your bank whether they can see any incoming wire record or advice.
Compare evidence quality before you act. Before you chase the wrong party, match the document to what it can actually prove.
| Evidence | What it proves | Best use | What evidence to request next |
|---|---|---|---|
| Sender-side payment record (for example, a bank receipt) | Sender-side outgoing payment record | Basic client communication | Ask for MT103 to support interbank trace work |
| MT103 | Interbank instruction was sent into SWIFT | Trace and bank-to-bank investigation | Ask for ACK/NACK/REJECT status and whether your bank sees an incoming advice or pending item |
| MT910 / account statement / bank-specific credit advice | Beneficiary-side credit confirmation | Confirming receipt | Ask whether credit is posted and available, or still on hold |
Use a simple status ladder so everyone is talking about the same stage:
MT103 can support stages 1 and 2 when paired with network status. It does not, by itself, prove stages 3 and 4.
If a client sends an MT103 or payment screenshot, forward the full document details to your bank's wire team and ask:
Use extra caution when documentation is incomplete, details do not match your invoice, or the sender will not request a bank trace. In those cases, wait for beneficiary-bank confirmation before treating the invoice as paid.
For a step-by-step walkthrough, see A Guide to the 'For Further Credit' (FFC) Instruction in Wire Transfers.
Do not wait passively. Use MT103 details to make the issue traceable: collect sender proof, route it to the right bank team, and match the delay to the most likely failure point.
Start with the sender, because the sending bank can initiate a formal trace using the payment reference. Request a complete proof pack in one message:
| Item | What to request | Note |
|---|---|---|
| MT103 | Full MT103 | Not a cropped screenshot |
| Sender bank reference | Sender bank reference | Request it in the same proof pack |
| Sender bank SWIFT code | Sender bank SWIFT code | Request it in the same proof pack |
| Amount and currency | Exact amount and currency sent | Request it in the same proof pack |
| Expected arrival date | Expected arrival date | Request it in the same proof pack |
| UETR | UETR | If available from the sender bank |
| Field 20 | Field 20 | The sender's reference |
In an MT103, Field 20 is the sender-assigned reference used to identify the message, so treat it as a core identifier for follow-up.
If you are still within the commonly cited 1 to 5 business day range, stay in status-check mode. If you are beyond that range, or the sender cannot confirm their bank started a trace, escalate immediately. Timelines can vary by bank, currency, and receiving-bank processing.
Watch for two clear escalation signals:
Do not mark the invoice paid or release deliverables until the case is verified.
Use frontline support to get to the right team quickly. Ask for the wire transfer team, international payments team, or incoming wire investigations team.
If your bank app or online banking shows detailed wire status, check it first. If no incoming item is visible, or support cannot interpret the status, move to the specialist team.
Give a complete handoff on first contact:
Ask two direct questions:
If they open an inquiry, get the case number before the interaction ends.
Once your bank replies, stop treating every delay the same. Use the response and the sender proof to narrow the failure point quickly.
| Likely failure point | What you will usually hear or see | Next action |
|---|---|---|
| Beneficiary data mismatch | Details do not match bank records, or sender details differ from your invoice or bank record | Recheck beneficiary name, account number, and receiving-bank details exactly. Ask the sender to confirm what was entered and have their bank amend, recall, or reissue where policy allows. |
| Compliance screening | Payment is under review, held for verification, or flagged by compliance | Ask your bank what they need from you. Ask the sender to check whether their bank must provide more information. Do not commit to a release timeline. |
| Intermediary/correspondent hold | Sender shows payment sent, but your bank has no final credit record | Ask the sender to push a formal trace through the sending bank using the reference and UETR. Ask your bank whether they can see any incoming item or intermediary routing clue. |
If funds arrive short, confirm whether intermediary or recipient-bank processing fees were deducted before treating it as a sender error.
Keep a case log. A simple log prevents repeat work and helps you escalate cleanly.
Track each follow-up until funds are credited and available:
If you want a deeper dive, read Separating Business and Personal Finances: A Important Step for LLCs.
Want fewer avoidable wire delays on future invoices? Standardize your client payment instructions with the Free Invoice Generator.
The best time to prevent a wire delay is before the invoice goes out. Use one repeatable process so MT103 evidence is for confirmation and tracing, not damage control.
This is a high-value control because small inconsistencies can create disproportionate delays. Use one master beneficiary profile, and match it character for character everywhere you share payment details.
| Field | Before sending | Where to compare |
|---|---|---|
| Full legal entity name | Match character for character | Invoice, saved bank profile, and payment instructions |
| Full beneficiary address | Match character for character | Invoice, saved bank profile, and payment instructions |
| Account number or IBAN, if used | Match character for character | Invoice, saved bank profile, and payment instructions |
| Bank name | Match character for character | Invoice, saved bank profile, and payment instructions |
| SWIFT/BIC | Match character for character | Invoice, saved bank profile, and payment instructions |
If any of these differ across your invoice, saved bank profile, or payment instructions, fix them before the payer sends. Small mismatches can trigger compliance holds and stall funds.
Agree the fee handling in writing before payment is sent. Field 71A defines who bears charges, so confirm whether the instruction is OUR, BEN, or SHA.
Also ask the payer to share a send summary with:
For traceability, capture the identifiers that track a specific payment: the 36-character UETR and the 16-character Field 20 sender's reference. A SWIFT/BIC identifies the bank, not the specific transfer.
Treat any new counterparty path as unproven, including the same client using a different sending bank or route. Before release, confirm beneficiary details, fee code, and core payment facts (amount, currency, and value date) against the invoice.
If a payment still stalls, escalate with the UETR and Field 20 reference ready. Manual traces may still be required in some cases, but they are slower and can add cost.
| Preventable failure mode | Upfront control | What to verify before sending |
|---|---|---|
| Data mismatch | Use one master beneficiary profile across invoice and bank instructions | Legal name, address, account number or IBAN, and bank identifiers match exactly |
| Fee-code confusion | Agree charge bearer in advance using Field 71A terms | OUR, BEN, or SHA is stated in writing |
| Traceability gaps | Capture payment identifiers at send time | 36-character UETR and 16-character Field 20 reference are recorded |
| Compliance data gaps | Share complete, consistent beneficiary and payment details early | Entity details, invoice amount, currency, and value date are consistent |
Format differences matter less than data quality. MT103 remains common evidence for wire payments, and SWIFT guidance includes coexistence handling, so the operational control is straightforward: tighten data checks instead of guessing at format differences.
Keep beneficiary naming consistent, avoid incomplete address details where full data is expected, and make sure the invoice amount, currency, and value date align with what the sender submits. That gives you a clean basis to reconcile the core payment facts and identifiers even when message formats differ.
You might also find this useful: What is an IBAN and How is it Different from a SWIFT Code?.
When a wire is delayed, treat the MT103 as an operations document. It helps you prove dispatch, identify mismatch risk, and run a formal trace.
An MT103 proves the payment instruction was sent. It does not prove the funds were received in the beneficiary account. Use Field 32A to confirm value date, currency, and amount, then check Fields 50 and 59 character for character against your records.
An MT103 alone cannot confirm final settlement. A short received amount is not always a delay, either. Under Field 71A BEN, fees across the chain can be deducted from what you receive.
Use the same escalation pattern every time:
This keeps you focused on evidence your bank can investigate. Payment exceptions are often manual and resource-intensive, so a process that keeps payment references, statuses, and records clear helps teams handle repeat tracing work consistently, whether you use Gruv or another platform.
We covered this in detail in Correspondent Banking Explained: Why Your International Wire is So Slow and Expensive.
If you want a more traceable payout workflow with compliance gates and audit-ready records where supported, see Gruv Payouts.
Ask the sender for the full MT103 or pacs.008 and the UETR if available. Verify Field 20 against the sender's reference and Field 32A against the expected value date, currency, and amount. Then ask the sending bank's wire or international payments team to run a trace using Field 20 and the UETR when available.
No. It confirms the sending bank dispatched the payment instruction, not that your bank received and cleared the funds. Wait for beneficiary-side credit confirmation before marking the invoice paid.
Because the MT103 confirms dispatch, not completion. A payment can still be delayed by data mismatch, compliance review, or intermediary-bank handling before final credit. Check that Field 20 and Field 32A match the expected transaction details, then ask for the latest trace status.
Yes. Do not trust the document's appearance by itself. Verify the references through official bank channels only, not links or bank sites shared by the payer. If fraud is suspected on an outgoing wire, contact both banks immediately and ask whether a recall is possible.
Timing varies by bank and payment corridor. Use your bank's verified current turnaround expectation. If the payment is already beyond the commonly cited 1 to 5 business day arrival range, escalate and confirm the sending bank has started a formal trace.
Fees depend on the bank and the request type. Ask your bank for its current fee range before requesting an MT103 copy or formal trace. Manual traces may be slower and can add cost.
A former product manager at a major fintech company, Samuel has deep expertise in the global payments landscape. He analyzes financial tools and strategies to help freelancers maximize their earnings and minimize fees.
With a Ph.D. in Economics and over 15 years of experience in cross-border tax advisory, Alistair specializes in demystifying cross-border tax law for independent professionals. He focuses on risk mitigation and long-term financial planning.
Educational content only. Not legal, tax, or financial advice.
For an LLC, separating business and personal money is best treated as a weekly habit, not a one-time bank setup. It keeps records cleaner, cuts month-end cleanup, and creates clearer boundaries as the company grows.
If your offshore entity, clients, or payment flow touches EU VAT obligations, make the compliance call early: lock your contract, invoicing, and VAT path before review pressure starts. For EU tax blacklist exposure, this is a revenue protection decision, not a policy debate.
The real problem is a two-system conflict. U.S. tax treatment can punish the wrong fund choice, while local product-access constraints can block the funds you want to buy in the first place. For **us expat ucits etfs**, the practical question is not "Which product is best?" It is "What can I access, report, and keep doing every year without guessing?" Use this four-part filter before any trade: