Pakistan’s Banks May Be Missing the Real Hawala Trail


Illustration of Raast hawala monitoring showing Karachi and Muscat, linked accounts, AML review, and cross-border payment patterns between Pakistan and Oman.
Pakistani banks need to look beyond individual Raast transfers and identify transaction patterns that may connect domestic payments with hidden cross-border hawala activity.

A Pakistani bank may see a normal Raast transfer.
The transaction that explains it may have started in Muscat.

FATF’s Oman case shows how a legitimate domestic payment can sit inside a wider hawala arrangement without Raast itself being compromised.

That changes the compliance question. Banks cannot rely only on transaction value or one isolated payment.

They need to examine customer behaviour, linked accounts and unusual transfer patterns.

The harder problem appears when one bank sees only one leg of the chain while foreign investigators hold the information that gives the payment meaning.

I examine how Pakistani banks can improve Raast monitoring without making the system slower or more difficult for legitimate users.

Read the full analysis:
https://www.munaeem.org/2026/09/raast-hawala-monitoring-pakistan-banks.html

Economic Choke Points Warfare in Global Payments Is Reshaping Power

Economic choke points warfare disrupting global payment networks and financial systems

The Quiet War Over Global Payments Has Already Begun. This conflict centres around economic choke points warfare and the ways nations seek power in the modern financial system.

Economic choke points warfare has entered the global payments system. It no longer sits only in oil routes or mineral supply chains. Instead, it now operates inside the networks that move money across borders. As a result, power is shifting quietly but decisively.

Why Global Payments Became a Strategic Lever


For decades, the United States shaped global finance through dollar clearing and systems like SWIFT. In practice, access meant participation, while removal meant isolation.


For example, sanctions on Iran cut banks off from international transfers. As a result, trade slowed and liquidity tightened. Similarly, Russian banks faced restrictions, which disrupted settlements across multiple sectors.


The scale explains the influence. According to the Bank for International Settlements, about 88 percent of global foreign exchange transactions involve the U.S. dollar. Therefore, the system reflects both trust and structural dependence.
At first glance, this looks like neutral infrastructure. However, it acts as a strategic lever.


How Rivals Adapted to Economic Choke Points Warfare


Once economic choke points warfare became visible, other countries adjusted their strategies. In response, they studied the system and began building alternatives.
China introduced CIPS to reduce reliance on SWIFT. At the same time, Russia expanded its SPFS network after sanctions pressure increased. In addition, several economies promoted bilateral trade in local currencies.


A textile importer in Karachi checks his phone again. The payment confirmation has not arrived. It used to take hours. Now it takes days. The container stays where it is.


The pattern is consistent. For instance, energy flows face pressure in the Strait of Hormuz. Likewise, supply chains tighten through rare earth controls. Now, payments form the next layer under strain.

What Fragmentation in Global Payments Looks Like


The system will not collapse suddenly. Instead, it will fragment over time.

First, parallel payment systems are emerging
Second, currency blocs are forming gradually
Third, access to liquidity is becoming conditional


A Pakistani exporter recalculates prices. Not because demand changed. Because settlement risk did.


As a result, predictability declines. Even small delays create hesitation.

Consequently, importers slow decisions, while banks increase compliance checks. Over time, confidence weakens across the system.


Why Economic Choke Points Warfare Is Hard to See


Sanctions are visible and widely reported. In contrast, payment friction operates quietly.


For instance:
A transaction is flagged
Then, a correspondent bank delays processing
Eventually, compliance checks extend timelines
No official ban exists. However, the outcome feels similar.
A bank officer in Karachi explains the delay without naming the cause. Still, the tension sits there. Everyone understands.
Therefore, speed becomes a tool of pressure. Not loud, yet highly effective.

Conclusion: Control Is Replacing

TrustEconomic choke points warfare is reshaping global finance. Increasingly, control over payment systems matters as much as economic strength.The United States still dominates global payments. However, other countries are building alternatives and reducing reliance on existing systems.

Somewhere between a delayed payment and a missed shipment, trust begins to weaken.In the end, once trust fragments, it rarely returns in full.

Why Banks Still Use Hybrid MT–MX Systems Despite SWIFT’s Long Migration Timeline

Did SWIFT Give Enough Time? Yes. So Why Are Banks Still Hybrid?

With the impending changes, many institutions are exploring hybrid MT-MX systems to ensure a smooth transition. SWIFT announced the ISO20022 migration years ago. In fact, banks received one of the longest notice periods in the history of financial messaging:

  • 2018: Early migration roadmap
  • 2019–2021: Release of CBPR+ rulebooks
  • 2022: Coexistence phase begins
  • 2023–2025: Gradual implementation
  • 2025–2026: Expected decommissioning of MT messages

On paper, this looked like a generous runway. Yet most banks in Asia, Africa, the Middle East, and even the United States still operate hybrid MT-MX systems today.

Hybrid MT-MX systems converting MT messages to ISO20022 MX format using an automated translation layer

There are reasons for this slow transition, and none of them are laziness. The reality is more complicated.


Legacy Core Systems Cannot Absorb ISO20022 Overnight

Many banks still run decades-old core systems built on COBOL or similarly rigid languages. These systems cannot store, parse, or use the massively expanded MX message structures — especially fields such as:

  • ultimate creditor/ultimate debtor
  • structured addresses
  • compliance-related attributes
  • purpose codes
  • LEI details
  • extended remittance information

Upgrading the core is like replacing a jet engine mid-flight; one small change affects:

  • posting
  • reconciliation
  • compliance
  • fraud systems
  • liquidity management tools

A hybrid MT-MX layer is simply safer.


Correspondent Banks Are Not Synchronized

SWIFT’s global network includes thousands of institutions, each at different stages of readiness.
If Bank A sends pacs.008 but Bank B still expects MT103, the payment stalls or is rejected.

Hybrid MT-MX systems ensure:

  • MT for partners still on legacy rails
  • MX for banks that already migrated

This avoids cross-border payment failures and ensures operational continuity.


ISO20022 Carries Far More Data — And That Creates Problems

Compared to MT messages, MX structures are far larger and far more structured.
Banks struggle with:

  • mandatory structured postal addresses
  • purpose-of-payment consistency
  • huge remittance blocks
  • stricter field validation
  • CBPR+ semantic rules

Many legacy AML tools and screening engines cannot handle this new level of detail, leading to false positives and processing delays.


Compliance Pressure Forces a Conservative Approach

CBPR+ is strict. Very strict.
Incorrect formatting can trigger:

  • message rejection
  • compliance flags
  • sanctions screening failures
  • delayed settlements
  • high repair queue volumes

Running a hybrid MT-MX model lets banks protect their internal processes while sending fully compliant MX messages externally through a conversion engine.


Vendors Themselves Were Not Ready

Payment hubs, AML tools, screening systems, and even some core banking providers underestimated the complexity of ISO20022.

Many vendors struggled to deliver:

  • end-to-end pacs.008/pacs.009 flows
  • structured data parsing
  • reconciliation via camt.053/camt.054
  • migration of RMA+
  • UETR lifecycle management

Banks had to wait for updates, patches, and certified releases before going fully MX.


Budget Constraints and Operational Priorities Slowed the Shift

ISO20022 migration is expensive.
Banks in South Asia, Africa, and the Middle East often prioritize:

  • cybersecurity upgrades
  • digital apps
  • regulatory reporting
  • branch network modernization

Payments transformation becomes “Phase 2”, not “Phase 1”.
Hybrid MT-MX systems deliver compliance without deep internal restructuring.


So Why Are Hybrid MT-MX Systems Still Used?

Because they work.
Because they reduce risk.
Because multinational banks and small local banks are migrating at different speeds.

Hybrid systems allow:

  • MT internally
  • MX externally
  • seamless conversion
  • compliance protection
  • lower operational disruption

Even in 2025–2026, hybrid coexistence will remain common across global correspondent corridors.

(All are authoritative sources for ISO20022 & CBPR+.)

pacs.008 Fields Explained in Simple English

When money is sent across borders under ISO 20022, banks use a structured message called pacs.008. In this article, we’ll have the pacs.008 fields explained for better understanding. This message is the ISO 20022 replacement for the old MT103 and is used for customer-to-customer international payments.

A pacs.008 contains two main parts:

  1. Group Header – Basic information
  2. Credit Transfer Transaction Information – The actual details of one payment

This post explains the second part, using simple language and clear examples anyone can understand.


Credit Transfer Transaction Information (Section B)

This section describes everything about one single payment:

  • Who is sending money
  • Who is receiving money
  • How much
  • Why
  • Which banks are involved
  • Who pays charges
  • How the transaction will settle

Below is a table showing each ISO 20022 field, a simple description, and a clear example.


Table explaining pacs.008 fields with descriptions and examples including settlement method.

Understanding Each Field (Plain English)


1. — Instruction Identification

A reference your bank creates to identify the payment internally.
Example: PKBR-2025-11-22-001


2. — End-to-End Identification

A reference that stays the same from sender to receiver.
Example: E2E-PKBK-908877


3. — Unique End-to-End Transaction Reference

A mandatory gpi tracking number used like a parcel tracking code.
Example: 55c1ca88-89f3-4e62-b3f5-112233445566


4. — Instructed Amount

Money the sender wants to transfer.
Example: USD 5,000.00


5. — Debtor

The customer sending the money.
Example: ABC Importers Ltd, Karachi


6. — Debtor Account

Sender’s account number or IBAN.
Example: PK49FAKE0000000123456789


7. — Debtor Agent

The sender’s bank.
Example: PKBAPKKXXXX


8. — Creditor

The customer receiving the money.
Example: Global Machinery GmbH, Munich


9. — Creditor Account

Receiver’s account number.
Example: 987654321


10. — Creditor Agent

The beneficiary’s bank.
Example: DEUTDEMMXXX


11. — Purpose Code

Reason for payment.
Example: CORT (Trade settlement)


12. — Remittance Information

What the payment is for.

  • Unstructured (simple text, 140 characters)
  • Structured (detailed invoice info, up to 9,000 characters)

Example:
Invoice 1217 for industrial pump


13. — Charge Bearer

Who pays the fees?

CodeMeaning
SHARShared charges
DEBTSender pays all
CREDReceiver pays all
SLEVSEPA rule

Example: SHAR


14. — Settlement Information (NEW SECTION ADDED)

Settlement Information tells how the payment will be settled between banks.

The most important element inside this block is:

— Settlement Method

This defines how the payment moves through the banking system.

ISO 20022 supports four values:

CodeMeaning
CLRGClearing system
COVECover method
INDAInstructed agent
INGAInstructing agent

Example Settlement Method:

INDA

This means the payment will settle directly through the instructed agent (the Creditor Agent).

This field is critical because it tells the receiving bank how to expect the funds.


Complete Real-World Example

A business in Karachi pays USD 5,000 to a supplier in Munich:

  • InstrId: PKBR-2025-11-22-001
  • EndToEndId: E2E-PKBK-908877
  • UETR: 55c1ca88-89f3-4e62-b3f5-112233445566
  • InstdAmt: USD 5,000.00
  • Dbtr: ABC Importers Ltd, Karachi
  • DbtrAcct: PK49FAKE0000000123456789
  • DbtrAgt: PKBAPKKXXXX
  • Cdtr: Global Machinery GmbH, Munich
  • CdtrAcct: 987654321
  • CdtrAgt: DEUTDEMMXXX
  • Purp: CORT
  • ChrgBr: SHAR
  • RmtInf: Invoice 1217 for industrial pump
  • SttlmMtd: INDA

This is exactly how the transaction appears inside a pacs.008 message.

SWIFT MX Message Terms Explained with Examples for ISO20022 Payments

ISO20022 MX has become the global standard for cross-border payments. But the system also produces long technical logs filled with fields most bankers see daily—yet rarely understand. This guide breaks down the most common SWIFT MX message terms with safe, clean, fictional examples.


1. Requestor DN (Distinguished Name)

The Requestor DN identifies the bank that initiates the MX message on the SWIFT network.

Example (fictional):
ou=cf-bnklpkka, o=swift

Breakdown:

  • bnklpkka → BIC of the sending bank (fictional)
  • ou= → organisational unit
  • o=swift → SWIFT domain

Meaning:
The message was pushed into SWIFT by the institution coded BNKLPKKA.


2. Responder DN

Shows which institution processed or received the message.

Example (fictional):
ou=cf-qtrfpkka, o=swift

Meaning:
The responding bank is coded QTRFPKKA (fictional BIC).

This field is helpful in reconciliation and payment investigations.


3. Service Name (finplus)

Indicates which SWIFT network service handled the message.

Example:
Service Name: finplus

Usage:

  • finplus → ISO20022 MX service
  • swiftnet → general messaging
  • retailplus → retail connections (fictional)

FINplus is now mandatory for all cross-border ISO20022 traffic.


4. Non-Repudiation Indicator

Shows whether SWIFT Non-Repudiation Service (NRS) is applied.

Example:
Non-repudiation Indicator: False

Meaning:
The message is not signed with non-repudiation cryptographic evidence.

If this were True, SWIFT could prove the origin of the message in compliance investigations.


5. SWIFT Reference (Generated by SWIFT)

A unique tracking ID created by SWIFT FINplus.

Example (fictional & safe):
swi0203027-09-18T14:22:45.983472_5598217Z

Breakdown:

  • 2027-09-18 → date of processing
  • T14:22:45.983472 → timestamp
  • _5598217Z → internal SWIFT sequence

This reference is used when tracing or recalling payments.


6. SWIFT Request Reference (Generated by the sending bank)

Unlike the SWIFT reference, this ID is generated by the bank’s own interface.

Example (fictional):
SNL5824420270918T142245B910_8821735

Purpose:

  • Internal reconciliation
  • Investigations of stuck or rejected messages
  • Reference between core banking and SWIFT gateway

Think of it as the “local tracking number” before SWIFT assigns its own.


7. CBT Reference (Cross-Border Transfer Reference)

This is the ID used inside the bank’s internal systems, usually a UUID.

Example (fictional):
7fa91372-89c1-4c61-a4c9-902d51b4e8dd

Used by:

  • AML screening
  • Treasury settlement
  • Payment repair teams
  • Nostro reconciliation

Every bank generates its own long-form internal identifiers.


8. Store-and-Forward Input Time

The moment the message entered SWIFT’s Store-and-Forward queue.

Example (fictional):
2027-09-18T14:22:45

This timestamp is essential for:

  • cut-off time disputes
  • SLA monitoring
  • operational reconciliation

9. Signing DN (Certificate Identity)

This identifies the certificate that signs the MX message.

Example (fictional):
cn=mxusr05, o=bnklpkka, o=swift

Meaning:

  • mxusr05 → SWIFT user/application signing the message
  • bnklpkka → fictional sending bank
  • o=swift → SWIFT network

Digital signatures ensure message security and authenticity.


10. Message Header (ISO20022 Type)

Identifies the MX message schema used.

Example:
pacs.009.001.10

Explanation:

  • pacs.009 → Financial Institution Credit Transfer
  • 001.10 → version 10 of the schema

Other common headers:

  • pacs.008 → Customer Credit Transfer
  • pacs.004 → Return
  • camt.029 → Investigation response
  • camt.056 → Cancellation request

11. AppHdr Block

Displayed as:
<AppHdr xmlns="urn:iso:std:iso:20022:tech:xsd:head.001.001.02">

Contains:

  • Sender BIC
  • Recipient BIC
  • Business Message Identifier
  • Definition Identifier
  • Creation timestamp

It is the “envelope” that carries routing and identification data.


Conclusion

Understanding SWIFT MX message terms helps operations officers, compliance teams, treasury staff, and payment processors handle ISO20022 transactions with confidence. Each term in the FINplus log has a specific purpose that supports security, traceability, and accurate settlement across the global financial network.