A Pakistani importer asks his bank to send $25,000 to a supplier in Germany. The bank checks the documents, debits the customer’s account and issues a payment instruction. A few hours later, the importer receives confirmation that the transfer has been sent. The German supplier checks his account. Nothing has arrived.

Where is the money? The answer lies in a banking system most customers never see. A SWIFT payment involves more than a message sent from one bank to another. Banks must arrange settlement through accounts they maintain with other financial institutions. Each bank may conduct its own checks before allowing the payment to proceed.

Having worked with SWIFT operations in Pakistan’s banking sector, I find one distinction particularly important: sending a payment message does not necessarily mean the beneficiary has received the money.

SWIFT carries instructions, not the money itself

SWIFT stands for the Society for Worldwide Interbank Financial Telecommunication. It operates a secure financial messaging network that banks use to exchange standardized instructions. A message identifies the financial institutions involved and provides payment details, including the amount and beneficiary. SWIFT does not itself hold the customer’s deposit or settle the payment between banks. Settlement occurs through banking accounts and payment arrangements outside the messaging network.

The journey of a $25,000 payment

Consider a fictional Pakistani company buying machinery from a German supplier. The invoice is for $25,000, payable in US dollars. The simplified route is: importer → Pakistani sending bank → SWIFT instruction → USD correspondent bank → German beneficiary bank → supplier. Actual message and settlement routes may differ and can involve several intermediary banks.

Step 1: The Pakistani bank examines the payment

The importer supplies an invoice and the documentation required for the transaction. The bank must establish that the payment meets applicable foreign-exchange rules, conduct customer due diligence and carry out relevant sanctions screening. Pakistan’s Foreign Exchange Manual provides the regulatory framework for authorized dealers. Payments for imported goods may require different documentation from payments for overseas services.

Step 2: The bank prepares its payment instruction

Banking professionals will remember the MT103 customer credit transfer. Following the end of the main cross-border payment-instruction coexistence period on 22 November 2025, ISO 20022 became the standard for those instructions on SWIFT. Customer credit transfers commonly use pacs.008. Legacy MT formats remain relevant in other services and contexts; not every MT message has disappeared. Structured ISO 20022 information can help banks automate processing and identify problems more accurately. See SWIFT’s ISO 20022 guidance.

Step 3: Correspondent banking connects the institutions

A Pakistani bank does not need an account with every bank in Germany. It can use correspondent banking relationships. Suppose it holds US dollars with a correspondent abroad. It may use that account to settle its obligation under the payment arrangement. Bankers call an account maintained with another bank a nostro account. If the receiving bank lacks a direct settlement relationship, another intermediary may be involved. The SWIFT message communicates the instructions; correspondent account entries settle the obligation.

Step 4: The correspondent bank processes the transfer

A correspondent may examine names, transaction details and institutions involved. Missing information or compliance concerns can lead to manual investigation. A payment can therefore leave the Pakistani bank’s processing system but remain under review elsewhere. Under certain arrangements, the payment instruction and cover funds travel through separate messaging paths. A receiving bank may know a payment is expected before it has the settlement assurance needed to credit the beneficiary.

Step 5: The beneficiary bank credits the account

After receiving the necessary instruction and settlement, the German bank processes the payment under its own procedures. It may need to verify account details or complete compliance checks. A payment can reach the beneficiary bank without being credited immediately. That distinction explains many customer disputes.

Why a SWIFT payment can be delayed

• Incomplete beneficiary details may trigger clarification or rejection.
• Compliance screening can require manual investigation.
• Missing cover funds may delay beneficiary credit.
• Cut-off times and bank holidays can shift processing to another business day.
• Currency conversion can add processing steps.
• Account restrictions can prevent a bank from crediting the beneficiary.

Not every delay indicates wrongdoing or a technical failure. Customers nevertheless deserve meaningful status information rather than repeated assurances that the payment is somewhere in the system.

What is a UETR?

Modern SWIFT payment instructions carry a Unique End-to-end Transaction Reference (UETR). This 36-character reference supports payment tracking across the chain. Customers may not have access to their bank’s full tracking interface, but they can ask for the UETR and available status information. A SWIFT network acknowledgement alone does not prove beneficiary credit.

What if the money never arrives?

Suppose the Pakistani importer sends $25,000 on Monday and the German supplier reports no credit by Thursday. The importer should ask the sending bank to establish the status, providing the date, amount, currency and beneficiary details. The sending bank can investigate through its operational channels and contact other banks if necessary.

A customer should not send a replacement merely because the original appears delayed: duplicate payment is possible. If the transfer is rejected or returned, the bank should explain the available return information and reconcile the funds received. Charges and exchange-rate effects may change the refunded amount. A recall request is not a guaranteed cancellation and may depend on another institution or the beneficiary.

Why ISO 20022 matters to Pakistani banks

ISO 20022 is not merely a technical exercise for SWIFT departments. Older message formats could contain information understandable to an operator but difficult to process automatically. Richer structured data can improve screening, reconciliation and exception handling. It cannot remove national regulatory differences or the need for correspondent settlement.

What Pakistani customers should understand

Customers should supply accurate information, retain payment documents and request clear tracking details when a transfer is delayed. For Pakistan’s foreign-exchange framework, consult my Pakistan Cross-Border Payments Guide and Pakistan Payments Guide.

The useful question is not simply whether the sending bank issued a SWIFT message. It is whether the payment completed settlement and reached the beneficiary’s account. Those are different events.