SWIFT

SWIFT Transfers and Communication with MT and MX messages

SWIFT (Society for Worldwide Interbank Financial Telecommunication) is a secure messaging network that enables financial institutions, such as banks, to send and receive standardized messages about financial transactions, like payment instructions and confirmations. SWIFT does not hold accounts or transfer funds; it simply provides a secure and reliable platform for exchanging information.

Normal SWIFT transfers use a series of standardized message types known as MT (Message Type) messages. These messages have predefined formats and fields, ensuring that financial institutions can easily understand and process the information they contain.

MX (ISO 20022) messages are a newer standard of financial messaging based on XML (eXtensible Markup Language). They provide a richer and more structured format, allowing for enhanced data exchange and improved straight-through processing. MX messages are gradually replacing MT messages in the SWIFT network, with the aim of providing better interoperability and data handling capabilities.

While traditional SWIFT transfers have been the backbone of international payments for decades, they have some limitations, including limited transparency, slower processing times, and unstructured data.

Swift 103+ STP (Straight Through Processing)

Swift 103+ STP was the legacy MT format optimised for Straight Through Processing (STP); since the end of coexistence its role is taken by the pacs.008 STP usage guideline. STP enables the entire payment process, from initiation to final settlement, to be conducted electronically without the need for manual intervention.

Additional Features:

1. Standardized Format: It requires strict adherence to a standardized format, reducing errors and delays.
2. Automated Processing: Transactions are processed automatically, ensuring faster and more efficient processing.
3. Reduced Manual Intervention: The need for manual entry and verification is minimized, reducing the risk of errors and delays.
4. Faster Settlement: Transactions are settled more quickly compared to traditional methods.

Considerations for STP:

1. Accurate Data Entry: Data must be accurately input to avoid delays or rejections.
2. Compliance with Format Requirements: Banks must ensure that the format requirements of 103+ STP are strictly followed.
3. Software and Systems: Banks need to have appropriate software and systems in place to handle STP effectively

It is essential to distinguish between messaging and settlement. SWIFT transmits structured financial messages between institutions, but it does not itself move funds or hold balances. A SWIFT confirmation, including a pacs.008 message, is only valid when it corresponds to an actual transaction processed and reconciled within the banking systems of the participating institutions.

Any standalone SWIFT document, screenshot, or message presented without institutional verification should not be treated as evidence of completed settlement.

SWIFT gpi transfers.

SWIFT gpi (Global Payments Innovation):

Launched in 2017, SWIFT gpi is an initiative designed to address the limitations of traditional SWIFT transfers by enhancing the speed, transparency, and traceability of cross-border payments. SWIFT gpi leverages the existing MT and MX message formats to improve payment services. Key features of SWIFT gpi include:

• Faster payments: gpi simplifies processes and establishes tighter service-level agreements (SLAs) between banks, resulting in faster transaction times, often within minutes or seconds.
• Payment tracking: The gpi Tracker enables real-time tracking of transactions, improving transparency and reducing manual investigations.
• Fee transparency: Banks can provide customers with information about transaction fees upfront, allowing for better decision-making.
• Richer data: gpi supports more detailed and structured information exchange, facilitating improved reconciliation and regulatory compliance.

SWIFT gpi addresses the limitations of traditional SWIFT transfers by enhancing cross-border payments with end-to-end tracking, faster processing, and richer data.

Key Parameters for Non-SWIFT gpi Participants

When a non-SWIFT gpi participant (e.g., a bank or financial institution not directly enrolled in gpi) sends a payment instruction to a gpi participant bank, the gpi bank can convert it into the required SWIFT message formats (pacs.008 for customer credit transfers, pacs.009 COV for cover transfers and pacs.009 for financial institution credit transfers). This conversion enables processing and tracking within the gpi network, provided the instruction includes sufficient data to populate mandatory fields and comply with gpi rules, such as end-to-end traceability.

Non-gpi participants typically provide these parameters via domestic payment schemes, APIs, or legacy formats, and the gpi bank handles gpi-specific additions (e.g., generating a UETR if not supplied, though passing it is optional for non-gpi entities). The exact requirements may vary by jurisdiction, currency, and bilateral agreements, but the core parameters are drawn from CBPR+ (Cross-Border Payments and Reporting Plus) guidelines and ISO 20022 standards. Since the end of coexistence on 22 November 2025, cross-border payment instructions are exchanged in ISO 20022 format; legacy MT field references below are given for orientation only.
1. Party Identification (Debtor and Creditor Details)
These identify the originator and beneficiary, ensuring compliance with FATF Recommendation 16 for travel rule requirements.

• Debtor/Ordering Customer: Full name, structured address (street, city, postal code, country), and account identification (e.g., IBAN or account number). In the former MT 103/MT 202 COV, this maps to Field 50a; for pacs.008/pacs.009, to <Dbtr> and <DbtrAcct>.
• Creditor/Beneficiary Customer: Full name, structured address, and account identification. Maps to Field 59a in the former MT 103/MT 202 COV; <Cdtr> and <CdtrAcct> in pacs.008/pacs.009.
• Ultimate Debtor/Creditor (if applicable): If different from the primary parties, include their details for enhanced transparency (optional but recommended for gpi tracking). Maps to <UltmtDbtr>/<UltmtCdtr> in pacs.008/pacs.009.

Why required: Enables accurate routing and regulatory checks; incomplete data may lead to rejects or delays.

2. Agent and Routing Information
Specifies the financial institutions involved in the chain.

• Debtor Agent: BIC (Bank Identifier Code) or other identifier of the sending bank. Maps to Field 52a in the former MT 103; <DbtrAgt> in pacs.008/pacs.009.
• Creditor Agent: BIC of the receiving bank. Maps to Field 57a in the former MT 103/MT 202 COV; <CdtrAgt> in pacs.008/pacs.009.
• Intermediary Agents (if known): BICs for any correspondents (up to 3 levels). Maps to Field 56a in the former MT; <IntrmyAgt1-3> in pacs.008/pacs.009.
• Instructing/Instructed Agents: BICs for the immediate sender/receiver in the chain. Optional but aids in serial or cover methods.
• Previous Instructing Agents (if applicable): For multi-hop chains, up to 3 prior agents.

Why required: Ensures proper intermediary routing; use BICFI over names for precision in pacs.009 COV.

3. Transaction Details
Core financial elements for settlement.

• Amount and Currency: Interbank settlement amount and ISO 4217 currency code (e.g., USD, EUR). Maps to Field 32A in the former MT 103/MT 202 COV; <IntrBkSttlmAmt> in pacs.008/pacs.009.
• Instructed Amount (if different): Original amount before deductions.
• Interbank Settlement Date: Value date for settlement. Maps to part of Field 32A in MT; <IntrBkSttlmDt> in pacs.008/pacs.009.
• Settlement Method: Indicate if via RTGS (CLRG), cover (COVE), or agent (INDA/INGA). No direct MT equivalent but implied.

Why required: Defines the value transfer; mandatory for all formats.

4. Reference and Tracking Identifiers
For traceability, especially in gpi.

• End-to-End Identification: A reference linking the entire chain (e.g., invoice or transaction ID). <EndToEndId> in pacs.008/pacs.009.
• Instruction Identification: Sender’s reference (limited to 16 characters in MT). Maps to Field 20 in the former MT; <InstrId> in pacs.008/pacs.009.
• Unique End-to-End Transaction Reference (UETR): A UUID for end-to-end tracking. Mandatory in pacs.008/pacs.009 and, in the former MT 103/MT 202, in Field 121; if an initiating channel does not supply it, the first Swift bank in the chain generates it.
• Transaction Identification: Additional internal reference.

Why required: Enables gpi tracking and linking (e.g., pacs.008 to pacs.009 COV); UETR is key for universal confirmations.

5. Purpose and Service Information
Classifies the payment type.

• Purpose and Category Purpose codes: ISO codes (e.g., SALA for salary) indicating the nature of the transaction. Required in certain corridors; <Purp> and <CtgyPurp> in pacs.008.
• Service Level Code: Identifies the gpi service (e.g., G001 for a gpi customer credit transfer); non-gpi banks should not include gpi-specific codes unless agreed. Maps to Field 23E in MT; <SvcLvl> in pacs.008/pacs.009.
• Local Instrument Code: For specific schemes (e.g., intragroup transfers).

Why required: Ensures regulatory compliance and processing priority; increasingly mandatory post-ISO migration.

6. Remittance and Additional Instructions

• Remittance Information: Unstructured (up to 140 characters) or structured (e.g., invoice details). Maps to Field 70 in the former MT 103; <RmtInf> in pacs.008/pacs.009.
• Instructions for Agents: E.g., /REC/ for receiver, /ACC/ for account, or phone instructions (PHOB). Maps to Field 72 in the former MT; <InstrForNxtAgt>/<InstrForCdtrAgt> in pacs.008/pacs.009.
• Settlement Time Indicators: Requested times (e.g., CLSTm for CLS time).

Why required: Provides context and handling instructions; essential for cover methods in pacs.009 COV.

7. Regulatory and Compliance Data

• Regulatory Reporting: Codes or details (e.g., tax ID, reporting indicator like CRED/DEB). Maps to Field 77B in MT; <RgltryRptg> in pacs.008/pacs.009.
• Return Reason Codes (if applicable for returns): E.g., AC04 for closed account, in pacs.004 linked to original messages.

Why required: Meets AML/KYC and reporting obligations; mandatory in regulated corridors.

For best practices, non-gpi participants should structure data to avoid truncation during MT-to-MX conversions and consult the gpi member bank for specific needs. If the payment involves cover methods, the underlying customer details must mirror across messages (e.g., pacs.008 to pacs.009 COV).

Payment Messages in SWIFT gpi

In the SWIFT gpi (Global Payments Innovation) framework, the original payment messages (e.g., pacs.008 for customer transfers or pacs.009 COV for cover transfers) are considered immutable once sent. Receiving banks cannot directly alter or modify the content of these messages, as SWIFT messages are designed to maintain integrity and auditability throughout the payment chain. Instead, any changes, corrections, or cancellations are handled through separate follow-up messages, status updates via the gpi Tracker, or dedicated services like gSRP (gpi Stop and Recall Payment). This ensures end-to-end traceability using the Unique End-to-End Transaction Reference (UETR).

Receiving banks (typically acting as the creditor agent or intermediary) can, however, respond to alteration requests from the sender or initiate actions that effectively result in modifications to the payment outcome (e.g., returns or holds). They can also request clarifications or amendments from the sender under specific conditions. These processes are governed by SWIFT’s rulebooks, market practice guidelines (e.g., from the Payments Market Practice Group – PMPG), and regulatory requirements, prioritizing automation, transparency, and fraud prevention.

Conditions for Receiving Banks to Request or Facilitate Alterations
Receiving banks may request alterations (e.g., corrections to details) or take actions that imply a need for change when the original payment cannot be processed as instructed. This is typically done via inquiry messages (e.g., MT 195/199) or responses to sender-initiated requests. Key conditions include:

• Errors in Payment Details: If there are inaccuracies such as incorrect beneficiary account (e.g., closed account – code AC04), wrong currency (code CURR), incorrect agent routing (code AGNT), or technical issues (code TECH), the receiving bank can place the payment on hold and request the sender to provide corrected information or send a new payment. This avoids outright rejection while allowing resolution.
• Inability to Apply the Payment: Under code CUTA (Cancel Upon Unable to Apply), if the payment cannot be credited due to mismatches (e.g., name/account discrepancy or insufficient details), the receiving bank can request cancellation or amendment details from the sender to remediate.
• Suspected Fraud or Unauthorized Transactions: For fraud (code FRAD), the receiving bank can independently detect issues and initiate a return of funds without a prior request from the sender. They can also respond to sender’s recall requests by quarantining funds and requesting indemnity (code INDM) if funds are already credited, to mitigate risk before returning.
• Duplicate or Undue Payments: Codes like DUPL (duplicate payment) or UPAY (undue payment) allow the receiving bank to flag and request cancellation if the transaction is erroneous or unjustified.
• Regulatory or Compliance Issues: If the payment violates local laws, sanctions, or AML requirements (code LEGL), the receiving bank can reject or hold it and request additional documentation or amendments from the sender.
• Customer or Beneficiary Decisions: If the beneficiary refuses the payment (code CUST or NOAS – no answer from beneficiary), the receiving bank can return it and notify the sender, potentially requesting confirmation of changes.
• Pending Resolutions: For pending cases (code PDCR), such as awaiting debit authority (RQDA) or reply from next agent (PTNA), the receiving bank can hold the payment and request further instructions or alterations to proceed.

In all cases, requests must be structured for automation (e.g., including UETR, original references like field 20/32A/50/59, and specific codes in field 79 of messages) to support straight-through processing. Indemnity agreements may be required bilaterally if funds are credited, and the receiving bank has no obligation to accept requests but must prioritize urgent ones (e.g., fraud-related).

Processes Involved

• Response to Sender-Initiated Recalls: The sender (debtor agent) typically initiates a recall via MT 192/292 (or ISO 20022 equivalents like camt.056) through the gSRP service, sent serially or directly to the receiving bank. The receiving bank must acknowledge immediately and respond with MT 196/296 (or MT 199/299 if structured), using codes like CNCL (cancelled), RJCR (rejected with reason), or PDCR (pending). If accepted, funds are returned via pacs.004 (Payment Return).
• Independent Actions by Receiving Banks: If fraud is detected internally, the receiving bank can return funds using pacs.004 with structured details, notifying via the Tracker for real-time status updates.
• Requests for Amendment/Clarification: Receiving banks use inquiry messages (e.g., MT 195/295) to request changes, such as additional details. This is common for on-hold payments.
• Tracker Integration: All actions update the gpi Tracker in real-time, accessible via APIs or GUI, ensuring visibility for all parties. gpi members must comply with mandatory rulebooks for gCCT (Customer Credit Transfer), gCOV (Cover), and gSRP.
• Limitations and Success Factors: Alterations are not guaranteed; success depends on the payment stage (easier pre-crediting), beneficiary cooperation, and jurisdiction. If credited, returns require beneficiary consent or indemnity. Regulations always supersede guidelines.

These practices apply primarily to gpi members, but non-gpi banks can participate via gateways. For the most current details, consult SWIFT’s official rulebooks, as processes evolve (e.g., with ISO 20022 migration).

Separation of Messaging and Settlement in SWIFT gpi

SWIFT gpi primarily handles payment instructions and tracking through messaging (e.g., ISO 20022 formats like pacs.008 for customer transfers, pacs.009 for financial transfers, or legacy MT 103/MT 202), but the actual movement of money occurs separately at the settlement level. Settlement typically happens via correspondent banking relationships (nostro/vostro accounts), bilateral netting, or Clearing and Settlement Mechanisms (CSMs) such as Real-Time Gross Settlement (RTGS) systems (e.g., T2, formerly TARGET2, in Europe, Fedwire in the US, or CHAPS in the UK). The gpi Tracker provides real-time visibility into message status, but funds transfer relies on these underlying systems.

The coexistence period for cross-border payment instructions ended on 22 November 2025: payment instructions such as MT 103 and MT 202 have been replaced by ISO 20022 (MX) messages such as pacs.008 and pacs.009, while other MT categories are being retired on later dates. The following explains how returns and hold releases occur at the account/clearing/settlement level.

How Money is Returned at the Account/Clearing/Settlement Level
Returns are initiated after a successful recall request (via gSRP – gpi Stop and Recall Payment service) or independent detection (e.g., fraud, errors). The gSRP uses camt.056 (Payment Cancellation Request) from the sender, answered with camt.029 (Resolution of Investigation). Once accepted, the return of funds is executed through a new payment instruction that reverses the flow, debiting the receiving bank’s account and crediting back through the chain. This is not an alteration of the original message but a separate transaction.

Key Settlement Methods and Return Processes
Settlement methods dictate how returns occur:

• CLRG (Clearing via Market Infrastructure): Settlement through an RTGS or CSM (e.g., via a central bank). Returns use pacs.004 to instruct the MI to debit the receiving agent’s account and credit the prior agent’s, often in real-time or same-day.
• INGA (Instructing Agent Settles First): Sender settles funds before messaging. Returns via pacs.004 debit the instructed agent’s account post-settlement.
• INDA (Instructed Agent Settles on Receipt): Receiver settles upon message receipt. If unsettled, reject via pacs.002 (no funds move); if settled, return via pacs.004.
• COVE (Cover Method): Used for high-value payments with a cover transfer (pacs.009 COV). Returns follow the reverse chain: pacs.004 from the beneficiary agent back to intermediaries, debiting/crediting correspondent accounts accordingly.

Step-by-Step Return Process at Settlement Level

1. Initiation and Acceptance: Sender requests recall (e.g., via camt.056 with UETR). Receiver responds (camt.029) and accepts if funds are available/not yet credited to beneficiary (easier pre-crediting). If credited, beneficiary consent or indemnity may be required.

2. Funds Return Instruction: Receiver issues pacs.004 (Payment Return) or legacy MT 103/MT 202 with return codes (e.g., RETN). This message includes:

• Original references (UETR, End-to-End ID, Instruction ID).
• Reversed roles: Original creditor becomes debtor; original debtor agent becomes creditor.
• Settlement details: Original Interbank Settlement Amount/Date, Exchange Rate (if FX involved), Charges (if deducted).
• Return Reason Code (e.g., AC04 for closed account, FRAD for fraud).
• Settlement Account field (if in original message) to specify the account for credit.

3. Settlement Execution:

• The pacs.004 triggers debit from the receiving bank’s nostro/vostro account (held with the prior agent or MI).
• Funds are credited back hop-by-hop through the chain, using the same settlement method (e.g., RTGS transfer in CLRG).
• If partial return, specify “PART” in Additional Information with prorated amount.
• Tracker updates status (e.g., “Returned”) in real-time, visible via API or GUI.

4. Final Credit: Original sender’s account is credited, often with deductions for fees. If via CSM, settlement is atomic; in bilateral setups, it may involve end-of-day netting.

5. Post-Return Notifications: Use camt.053/054 (Account Statement/Debit-Credit Notification) to confirm ledger updates. No further pacs.004 for “returning a return”: use inquiries instead.
Returns are automated where possible, but manual intervention may occur for compliance or if funds are frozen. Recovery is not guaranteed; it depends above all on how quickly the recall is sent and whether the funds have already been credited. If unsettled (e.g., rejected pre-settlement), no funds move: use pacs.002 instead.

How Held Payments Are Released (Green-Lighted) at the Account/Clearing/Settlement Level

Holds occur when a payment cannot be immediately processed (e.g., due to errors, compliance checks, or awaiting clarification), placing it in a “pending” state without settlement. No funds are debited/credited until resolution. The gpi Tracker shows statuses like “On Hold” or “Pending” (e.g., PDCR code), and resolution uses inquiry messages (MT 195/199 or camt.029).

Conditions Leading to Holds

• Mismatches (e.g., account/name discrepancy – CUTA code).
• Regulatory checks (e.g., sanctions – LEGL code).
• Awaiting beneficiary response (NOAS code) or debit authority (RQDA).
• Offline hours or batch processing at beneficiary bank.

Release Process at Settlement Level
1. Hold Notification: Receiver sends pacs.002 (status update) or MT 199 with pending code, holding funds in a suspense/escrow account if partially settled (e.g., in cover methods).
2. Resolution: Sender provides amendments/clarifications (e.g., via MT 195 response or camt.029). If resolved, receiver “green-lights” by processing the original instruction.
3. Settlement Execution:

• The original pacs.008/pacs.009 is released from hold.
• Funds settle via the specified method: Debit sender’s account, credit receiver’s (e.g., via RTGS in CLRG), then final credit to beneficiary’s account.
• The beneficiary leg (receiving bank to end customer) is often where delays occur, particularly in markets with capital controls or limited infrastructure.
• Tracker updates to “Credited” or “Completed,” with pacs.002 (Payment Status Report) confirming.

4. If Not Released: If unresolved (e.g., after timeout), return via pacs.004 as above, or reject with pacs.002 (no settlement).

gpi rules require same-day crediting where possible; Swift reported in 2018 that nearly 50% of gpi payments were credited within 30 minutes and almost 100% within 24 hours. Factors like capital controls or bank offline hours can extend holds, but gpi emphasizes automation to minimize them.

SwiftNet Instant

SwiftNet Instant. It is a real-time, low latency messaging platform that is available 24/7 and supports the secure exchange of instant payment flows between Clearing and Settlement Mechanisms (CSMs) and their participants.

Customers can connect to SwiftNet Instant through their existing Swift connectivity and security infrastructure, including VPN boxes, leased lines and hardware security modules. Integration with the bank’s IT environment is achieved through the Alliance Gateway Instant (AGI).

All parties along the instant payment chain can use AGI and SwiftNet Instant messaging. Applications include payment initiation from an overlay service, indirect member communications with a sponsoring member, or a corporate receiving a payment confirmation.

SWIFT Instant connects with domestic instant payment systems to enable real-time transaction processing, both domestically and internationally, using the ISO 20022 standard. These systems represent ongoing efforts to modernize and simplify payment processes in the financial industry.

SWIFT Direct Debit

Direct debit in the SWIFT system is a payment method that allows businesses and individuals to collect funds from debtor bank accounts in multiple currencies and across different countries. Unlike SEPA Direct Debit, which is specifically designed for the SEPA zone and is limited to euro-denominated transactions, direct debit in SWIFT has a global scope and supports a wide range of currencies.

The process of initiating a direct debit transaction within the SWIFT system typically involves the following steps:

1. Agreement between creditor and debtor: The creditor and debtor must have a pre-existing agreement, which includes the terms and conditions for direct debit transactions. This agreement may also involve setting up a mandate or authorization, allowing the creditor to collect payments from the debtor’s bank account.
2. Message exchange: The creditor’s bank initiates the direct debit by sending a SWIFT message to the debtor’s bank – in ISO 20022 a pacs.003 (customer direct debit) or pacs.010 (financial institution direct debit), formerly MT 104 or MT 204. This message contains the details of the transaction, such as the amount, currency, debtor’s account information, and any other necessary information.
3. Verification and authorization: The debtor’s bank verifies the transaction details, checks the availability of funds in the debtor’s account, and confirms the authorization for the transaction. If everything is in order, the debtor’s bank proceeds to debit the funds from the debtor’s account.
4. Funds transfer: The funds are settled between the debtor’s bank and the creditor’s bank through correspondent accounts or a clearing and settlement system.
5. Confirmation: Upon receiving the funds, the creditor’s bank sends a confirmation message to the creditor, notifying them of the successful direct debit transaction.

The prerequisites for initiating a direct debit transaction within the SWIFT system are as follows:

1. Bank accounts: Both the creditor and debtor must hold bank accounts with financial institutions that are part of the SWIFT network.
2. Agreement and authorization: A pre-existing agreement and authorization (mandate) between the creditor and debtor must be in place to enable direct debit transactions.
3. SWIFT message formats: The creditor and its bank must use the appropriate message formats: pain.008 to initiate a direct debit, pacs.003 or pacs.010 between banks.
4. Bank fees: The creditor and debtor should be aware of any fees associated with direct debit transactions within the SWIFT system, as these fees may vary depending on the banks and countries involved.

RMA in Interbank SWIFT Messaging

In banking and finance, secure and efficient communication between banks is essential. This is where SWIFT (Society for Worldwide Interbank Financial Telecommunication) plays a crucial role, carrying the majority of international bank-to-bank messages. A critical component ensuring the security and selectivity of these communications is the Relationship Management Application (RMA).

What is RMA?

Relationship Management Application (RMA) is a SWIFT software application that allows financial institutions to define which counterparties can send them SWIFT messages and ensures that SWIFT network communication is restricted to authenticated users only. RMA is a fundamental security layer in the management of interbank communication, as it filters out unauthorized messages and reduces the risk of fraud.

The Importance of RMA

For banks engaged in international finance, such as IFB, the RMA tool is indispensable. It not only reinforces security protocols but also ensures compliance with global banking regulations. By managing which institutions can send messages to them, banks can prevent unauthorized information requests and financial instructions, protecting both their interests and those of their clients.

How RMA Works

The RMA process involves several key steps:

1. Establishing RMA Relationships: Before two banks can begin exchanging information via SWIFT, they must mutually agree to establish an RMA. This agreement is akin to a digital handshake, signifying trust and consent to communicate.
2. Exchanging Keys: Each bank sends an RMA authorisation through the RMA application, which the counterparty accepts. RMA replaced the earlier bilateral key exchange (BKE); messages themselves are authenticated through SWIFTNet PKI (Public Key Infrastructure).
3. Configuring RMA Settings: Each bank uses the RMA tool to configure permissions and specify which types of messages are accepted from the other bank. This can be broadly categorized or finely tuned to include specific message types and subclasses.
4. Activation and Monitoring: Once RMA settings are configured and activated, banks can monitor incoming messages for compliance with the established permissions. RMA also provides tools to modify or revoke permissions if business needs or security concerns dictate.

Practical Applications

For IFB, which specializes in investment and wealth management for high-net-worth individuals and corporate entities, RMA provides several benefits:

• Enhanced Security: By controlling message traffic, IFB can secure client transactions and sensitive information against unauthorized access.
• Operational Efficiency: Streamlined communications with trusted entities ensure faster processing of legitimate messages, improving response times and client satisfaction.
• Regulatory Compliance: RMA aids in compliance with international banking regulations, which mandate strict control over information exchange to prevent financial crimes such as money laundering and fraud.

RMA and MT799. Banks may use an MT799 to request or coordinate an RMA relationship, provided the channel permits it. The RMA authorisation itself is granted in the RMA system; an MT799 alone activates no permission. Where the RMA authorisation required for MT799 is missing, it cannot be bypassed by sending an MT799 directly. The set-up is then agreed through the RMA communication feature of Swift’s Relationship Management Portal, designed for coordination with counterparties before authorisations are exchanged, or through another permitted channel. “RMA by MT799” can therefore describe the accompanying bank correspondence; the technical RMA authorisation is a separate step.

In short

For IFB, effective implementation of RMA is not just a technical requirement but a strategic asset in its global operations. It reinforces the bank’s commitment to security and regulatory compliance, while enhancing the efficiency of its communication networks. As the environment of international finance continues to evolve, tools like RMA remain essential in the arsenal of banks committed to maintaining the highest standards of operational integrity and client service.

RMAs form the backbone of secure and selective interbank communication, ensuring that every message exchanged via the SWIFT network adheres to the highest standards of security and is fully authenticated. For banks like IFB, understanding and managing RMAs is crucial to safeguarding their operations and building trust with their global partners.

Swift Digital Blockchain Financial Instructions

In September 2025 Swift announced that, together with over 30 financial institutions, it had begun designing and developing a shared digital ledger. On 9 July 2026 Swift declared the ledger ready for initial use, with 17 banks preparing to pilot live tokenised-deposit transactions: ANZ, BNP Paribas, BNY, Citi, DBS, First Abu Dhabi Bank, FirstRand, HSBC, Itaú Unibanco, Lloyds, Mashreq, MUFG, OCBC, Standard Chartered, UBS, UOB and Wells Fargo. The first application will focus on enabling real-time, 24/7 cross-border instructions between banks – a critical enhancement to the fabric of international transaction processing.

The first conceptual prototype was built with Consensys. The ledger is designed as a secure, immutable, and real-time register of financial instructions between institutions. It will record, sequence, and validate transaction messages, while enforcing operational and compliance rules through smart contracts. Interoperability is a central principle: the ledger will connect with both existing and emerging infrastructures, while maintaining Swift’s hallmark resilience, trust, and regulatory adherence.

As Swift’s Chief Executive, Javier Pérez-Tasso, explained:
“Combining a shared ledger with Swift’s existing messaging, APIs and ISO 20022 creates an even more powerful construct – one that can embed risk, controls and compliance requirements from the outset into transaction flows while enabling real-time 24/7 interbank cross-border instructions with the same trust, security, resilience, scalability and operational excellence Swift is known for. All in line with the approach we’ve always taken of responsible innovation.”

Extension of Infrastructure

The shared ledger complements Swift’s existing rails; it does not replace them. It is designed to extend orchestration and interoperability, ensuring that financial institutions can exchange instructions faster, with greater predictability, and at a truly global scale.

At Sibos, Pérez-Tasso underlined this dual-track approach:
“Financial infrastructures need to keep relentless focus on the fundamentals of operational excellence, regulatory compliance and governance. And at the same time, they need to get ready for the future. And at Swift, our approach is to innovate across two parallel tracks.”

Collaboration Across the Industry

Financial institutions from 16 countries were engaged from the outset in shaping the design, governance, and development path of the shared ledger. This collective effort underscores a shared recognition: advancing the global infrastructure for interbank instructions requires scale and collaboration.

Looking Ahead

The shared ledger is a natural progression of Swift’s earlier digital asset trials and is part of a broader commitment to interoperability across both public and private networks. This will allow regulated tokenised value and traditional instruments alike to move smoothly between systems.

Pérez-Tasso summarised the vision:
“This is a powerful platform for the future. And it can be even more transformational in the future.”

FAQs

What is the Swift blockchain-based shared ledger?
A blockchain infrastructure providing a shared, real-time record of financial instructions between institutions, enabling continuous, compliant, cross-border processing.

Who is it for?
Banks and financial institutions that must deliver faster, more transparent transaction instructions while preparing for the digital future.

What are the benefits?

• Real-time visibility and sequencing of instructions
• Automated compliance via smart contracts
• Interoperability across traditional and digital networks
• Secure handling of regulated tokenised value flows

How does it fit with Swift’s platform?
It extends Swift’s trusted infrastructure, embedding digital instruction capabilities while maintaining resilience, security, and compliance.

What is the first use case?
Real-time, 24/7 cross-border interbank transaction instructions.

Who is involved?
Over 30 financial institutions from 16 countries helped shape the design; 17 banks are piloting the first live transactions.

When will it be available?
Swift declared the ledger ready for initial use on 9 July 2026. The pilot banks run initial live transactions in a controlled go-live phase; final settlement still runs through existing systems. Functionality and availability are to be expanded afterwards.

If you want to know more about how to transfer funds through the corresponding banking system, please get in contact with our Head of Corresponding Banking M. Amri Elarisse