Building a high-performance middleware for SWIFT MT/MX Message Transfers using WSO2

LAST UPDATE: 30/07/2025

AUTHOR: Anuradha Prasanna. CTO Chakray APAC

Executive summary

As cross-border payments and domestic fund transfers are essential nowadays but also increase in complexity. Many financial institutions face mounting pressure to deliver faster, more secure, and highly reliable payment services making integrating to their core business systems. 

This technical white paper presents a real-world implementation of a robust API and integration middleware solution designed to handle SWIFT MT and MX message transfers through both the SWIFT global network and local RTGS systems. Built using WSO2 technologies, our solution addresses stringent secure architectural requirements such as guaranteed delivery, high availability, regulatory compliance, and detailed auditability.

Background on SWIFT and MT/MX messages

The SWIFT (Society for Worldwide Interbank Financial Telecommunication) network is the de facto global standard for secure financial messaging. It connects over 11,000 financial

institutions in more than 200 countries. Messages exchanged over the SWIFT network adhere to well-defined standards: MT Message Type) series: Legacy format, structured as flat key-value blocks.

• MT103: Used for single customer credit transfers, typically between banks on behalf of customers.
• MT202: Used for financial institution transfers, often to move funds between banks.
• MT202 COV: Variation that includes cover payment details referencing the original MT103.
• MX (XML-based messages): Based on the ISO 20022 standard, intended to replace the MT format gradually. Rich in semantics and supports structured data making more extended capabilities within the modern financial industry usecases and requirements.

Architectural drivers and requirements

To meet the rigorous demands of financial messaging, our solution was designed around the following critical non-functional requirements:

• Guaranteed delivery: Ensures every valid message reaches its destination reliably, even in the face of transient failures. We used modern lightweight message broker systems store and forward the SWIFT messages which provides handling large amount of messages delivered in a reliable way even if the connectivity to SWIFT/RTGS networks are temporarily disrupted.
• High Availability (HA): All components are deployed in clustered configurations with failover and load balancing. From the point to APIs that accept omni-channel tranfer request to the point where the actual messages are dispatched from the middleware solution, every process and the integration is highly available to make services available throughout the clock.

We leveraged the modern and de-facto deployment platform capabilities of Kubernetes to make this happen. This Kubernetes capability also brings high availability further enhanced with zero downtime deployments where application patches/fixes/deployments are done with zero interruptions to the clients.

It may interest you: How to implement WSO2 open source middleware to provide business flexibility

• Security and compliance: Adhering to TLS-v1.2-based secure communication, digital signatures, message integrity validation, and role-based access controls are in place to make the end-to-end solution secure. On top of these all communications with third-parties including SWIFT net is secured with secure tunnels to further enhance the security.

Every password related to secure endpoints, databases are securely stored or configured with strong encryption mechanisms such as RSA. Even further those secure configurations are versioned controlled in to a private git repository with re-encryption at git commit/push so that they are double encrypted with strong encryption with different private keys.

• Auditability and traceability: Every action, state transition, and message lifecycle is recorded and queryable. This is done with database audit records and instrumentation logs streamed to Elasticsearch based log-aggregation platform. Any failure during the processing generates a descriptive log in Elasticsearch as well as updated the database audit records with transaction status and the error details.
• Scalability: Capable of handling high transaction volumes with horizontal scalability with multi deployments on the Kubernetes platform which can withstand the various traffic patterns.
• Cut-off time awareness: Enforces processing logic based on network-imposed windows to comply with SWIFT/RTGS SLAs.
• Persistence: All request and state changes are recorded in a highly available Oracle RAC system with application connections made using Oracle SCAN based load balancing solution.

Solution Architecture Overview

The middleware comprises several coordinated components designed for message integrity, resilience, and compliance:

1. High-availability API Gateway (WSO2 Micro Gateway)

• API gateway layer protects the integration solution acting as a proxy to the real service that can impose TLS offloading and API throttling.
• Defined using OpenAPI specifications for full lifecycle management and documentation.
• Enforces authentication OAuth2, JWT, IP whitelisting, and rate limiting.
• Deployed in HA clusters behind load balancers for zero-downtime operations.
• Acts as the first layer of defense and logging.
• Deployed as microservices so that function oriented service deployments provide optimal operation and performance. This also makes overall deployment time much slower due tothe faster build/deployment and application startup time.

Keep reading: WSO2 API Microgateway: what it is, functions and implementation

2. Request validation and business rule enforcement (WSO2 Micro Integrator)

• Mandatory field and schema validation against SWIFT-defined message structures.
• Duplicate transfer detection based on transaction references or unique message IDs.
• Business rule checks, including:
  • Amount threshold validations
  • AM (Anti Money Laundering) integration validation to comply with international/local business needs
  • Sanctions screening (via external API or internal watchlist)
• Custom routing rules based on currency, beneficiary country, and urgency.
• Impose pre-determined data: Allow only approved currencies and custom exchange rates to be used

Keep reading: How to easily create and deploy a microservice with Micro Integrator

3. Persistent audit and tracking

• Dedicated audit tables maintained in Oracle RDBMS, but it can be maintained in a any other RDBMS:
  • Key transfer details such as transfer reference, amount, currency, originating/ordering customer account, transfer instructions/narrations among the key business information recorded for audit purposes
  • Request ID, timestamps of critical state changes along with the state transitions itself
  • Validation outcomes (Eg. invalid amount errors Or if the transfer is a duplicate request etc,)
  • Business error validation statuses (Eg. insufficient account balance on ordering customer account)
  • Constructed MT/MX message formats for deeper troubleshooting needs (in encoded format)
  • Posting and delivery acknowledgments
  • Retry counts/attempts in case of message delivery failures
• Enables real-time dashboards for tracking and compliance reporting are available in SWIFT GPI tracer, however API based transfer request information is available to be integration for any visualization dashboards if required.
• Grafana and Kibana based monitoring dashboards to visualize the processes and capture any message processing bottlenecks or errors occurred during the processing.

4. Financial ledger preparation and Core Banking System (CBS) Posting

• Interface with master-data repositories for CBS integration dependencies:
  • Customer and account details such as balance check before approving the transfer
  • Institution BIC codes and correspondent arrangements
  • FX rates for currency conversions between account and transfer currencies
  • Fee structures and configurations for various commissions and processing fees to be applied
• Constructs double-entry legs for debit and credit.
• Posting to core banking via secured, authenticated REST/SOAP APIs.
• Implements retries and compensation logic on failure.
• Adapter mechanisms when connecting with CBS systems so the CBS system is decoupled with integration system
• Externalyzed configurations so that pointing CBS instances/profiles are done with config changes such as environment variable changes

5. Swift MT/MX message construction

• Ability to generate financial messages such as MT103, MT202 or PACS.008
  • SWIFT message generation based on ISO standards using:
  • Field validation logic (e.g., field 50, 59, 70 in MT103
  • MX schema definitions (e.g., pacs.008.001.08
  • Use of templates and metadata mapping rules
  • Use of reusable templates to generate message references
  • End to end delivery network with use of field 50:, 52A:, 53A: 56A:, 57A:, 58A: and 59: etc
• Generate bilaterally (between banks and RTGS systems) compliance requirements with field 72: to indicate invoice numbers/government payment references etc.
• Messages enriched with institution-specific headers and routing instructions. Eg. to deliver to local RTGS service via Y-Copy services if the beneficiary BIC is a local bank/institution
• Y-Copy tag for local settlement entity. Eg. central bank) authorizations and priority flags are automatically injected based on recipient configuration.

6. SLA & cut-off time enforcement

– Configurable cut-off times for SWIFT and RTGS networks.

• Transfers submitted beyond cut-off are either automatically rescheduled to the next business day or posted by advancing the transaction day based on the configurations.
• Ensures compliance with settlement windows and mitigates late settlement risk.r

7. Dynamic routing and correspondent selection

• Logic-driven selection of intermediary (correspondent) banks based on:
  • Transfer currency
  • Destination BIC and jurisdiction
  • Cost-effective routing paths
  • Supports fallback correspondents and prioritization.

8. Guaranteed delivery via ActiveMQ

• ActiveMQ classic configured in clustered, persistent mode with:
• Guaranteed message delivery (JMS durable subscriptions)
• Retry and dead-letter queues
• Monitoring via Jolokia and Prometheus exporters
• Enables decoupling between message creation and transmission for fault tolerance.

9. SWIFT and RTGS network integration

• Outbound processors consume from queues and deliver to target networks:
  • SWIFT Alliance Access adapter (for MT/MX message injection)
  • RTGS integration via secure file drop, SFTP, or SOAP/REST gateways
• Status callbacks and confirmations are consumed and persisted.
• Resubmission logic for temporary network failures.

Keep reading: What are the differences between REST and SOAP?

10. GPI compliance

To align with SWIFT GPI (Global Payments Innovation) standards—which emphasize speed, traceability, and transparency in cross-border payments—we implemented the following

enhancements:

• Minimized/streamline processing: Efficient same day message delivery or deliver within 2 hours.
• MT199 notification messages: Automatically generated MT199 messages are sent at key stages of the payment lifecycle (e.g., initiation, processing, completing, rejection, settlement etc.) to inform correspondent banks of the payment status.
• UETR (Unique end-to-end transaction reference): A globally unique identifier is assigned to each payment and included in the SWIFT message header (block 3, field 121. This allows full end-to-end traceability across all intermediary banks in the payment chain.
• Enhanced charges breakdown: The SWIFT message block 4 is enriched with detailed fee/charge information using fields like 71A, 71F, and 71G. This can indicate internal processing fees and overseas charges etc.
• Real time status updates: The system consumes GPI tracker callbacks or queries the SWIFT Tracker API (if integrated) to update message statuses and audit logs. 

These enhancements ensure compliance with GPI rules, reduce investigation cycles, and improve customer transparency.

Security and compliance measures

• End-to-end encryption using TLS 1.2/1.3 
• Token-based authentication
• JWT/OAuth2) for API access
• A secure token endpoint service to generate OAuth2/JWT tokens in a secure way
• Message integrity validation (SHA 256 digests, MACs)
• Audit logging for every access and mutation
• Compliance alignment with SWIFT Customer Security Programme (CSP)

Business benefits and impact

• Operational resilience: Fault-tolerant queues and HA components ensure message delivery continuity. These message oriented architecture is resilient in case of a service restart or a crash.
• Speed and automation: Eliminates manual intervention by automating validations, postings, and message formatting. Further the processing is carried out in a bon-blocking manner (asynchronously) without the need to keep the client application in a waiting state. Client will be acknowledged via a API callback once the processing is completed. This make the systems loosely coupled making either side unavailability (may be due to network interruptions) not impacting the overall process.
• Regulatory compliance: Detailed audit trail supports internal audits and regulatory scrutiny while every sensitive information is recoded/configured as assymetric-key based encryption.
• Future-readiness: Supports both MT and MX formats, enabling a seamless transition to ISO 20022 standards. Having different versions os the API for MT or MX while keeping the API contracts exactly the same makes a smooth transition from MT messages to ISO20022 based MX messages while even enabling A/B type tests possible as well.
• Customizability: Easily adapted to institution-specific policies, local central bank mandates, or global standards due to the modulerized manner of implementing different segments of logic in to different components. Additionally all the credentials, configurations, endpoints are externalized from the code so the changes can be done without touching the business logic.

Conclusion

Business use case implementation demonstrates herein proposes a production-grade, highly scalable, and standards-compliant architecture for managing financial message flows via SWIFT and RTGS.

By leveraging WSO2’s open-source and extensible platform, we have delivered a solution that meets the highest expectations of modern financial infrastructure— without compromising on speed, security, or reliability. This solution is suitable for focused anysized financial organization that has a small to considerably large customer base.

Whether your institution is modernizing its payment rails, expanding into new markets, or seeking to improve operational controls, our robust payment handling solution can serve as a foundational component in your digital transformation strategy.

Get in touch to learn more about how we can customize and deploy a similar solution for your financial institution, please contact our team at info@chakray.com.

Talk to our experts!

Contact our team and discover the cutting-edge technologies that will empower your business.

contact us