Banking Middleware: RabbitMQ and Kafka for Payments, Trading and Insurance

Banking middleware: what it is and which parts we support

Banking middleware is the layer that moves data between a bank's systems: core banking, payment hubs, digital channels, fraud and risk engines, and reporting. In practice it is brokers, event streams, caches and integration software. AceMQ designs and supports the messaging and data layer, and connects to the systems of record rather than replacing them.

No single product dominates. IBM MQ is entrenched for transactional messaging because it has earned the place, and Kafka and RabbitMQ carry newer payment and event flows. Many banks run more than one, so one support contract across them avoids a dispute over whose platform an incident belongs to.

One SLA across messaging, caches, databases and search is described on enterprise support

Payment messaging: ISO 20022, Swift and 24x7 operation

ISO 20022 and Swift are not alternatives. ISO 20022 is a message standard: a common, data-rich XML format for payment messages. Swift is the network and messaging service that carries many of those messages between banks. Swift ended the coexistence period for cross-border payment instructions on 22 November 2025, so a Swift messaging system now sends and receives ISO 20022 (MX) messages where it used to use the legacy MT formats.

For the broker behind ISO 20022 payments, the change mostly means bigger messages and more validation. Message size limits, memory and disk headroom, and consumer processing time are worth re-checking when higher volumes of larger payloads arrive, and we include them in a health check.

• Keep payments flowing during an upgrade — A RabbitMQ upgrade can be rolling, node by node, or blue-green where the version path does not allow a rolling upgrade. We plan which applies and keep senior engineers on the line through the window.
• Legacy MQ behind the payment hub — Mainframe and IBM MQ queues move in phases with parallel running, not in one cutover.
• License floor — Broadcom's standard channel applies a 72-core minimum order for RabbitMQ. AceMQ licenses beneath that floor, so a smaller estate is priced on the cores it has.

Rolling and blue-green upgrades are compared in upgrading RabbitMQ 3.x to 4.x without downtime

The per-core model and the minimum are explained on RabbitMQ licensing

For moving payment flows off ageing queues, see legacy messaging modernization

Payment and trade event streams: choosing and hardening the broker

Payment and trade flows put opposite pressures on a broker. A payment queue needs every message to survive and none to be applied twice. A trade or event stream needs many consumers reading the same ordered events, with the ability to replay them. The broker follows from which of those a flow is.

The payment design points are not theoretical. RabbitMQ publisher confirms tell a publisher whether the broker accepted a message, and for persistent messages on durable queues the confirm follows the write to disk. Quorum queues confirm only after replication to a quorum. Consumers still have to be prepared for redelivery, because the same documentation says deliveries are requeued when a channel closes and that consumers should be implemented with idempotence in mind.

On Kafka, the delivery guarantee is at-least-once by default. Kafka supports exactly-once processing with transactions between Kafka topics, while writes to outside systems need the other system's cooperation. For a ledger that sits outside Kafka, that makes idempotent writes keyed on a transaction identifier the safe design.

A payment-system resilience case, from a Fortune 500 financial services company, is in the payment resilience use case

A retry and back-pressure case from a payment exchange service is in the retry automation use case

A service-level Kafka throughput example for a banking transaction platform is in the Kafka transaction throughput use case

A multi-broker review for an online trading platform is in the trading platform assessment use case

For how the brokers differ, read RabbitMQ versus Kafka

Capital markets: a post-trade event backbone for T+1

T+1 means a trade settles one business day after the trade date instead of two. The US moved on 28 May 2024, with Canada and Mexico a day earlier on 27 May. The UK, the EU and Switzerland are aligned on 11 October 2027. Under T+1, allocation, confirmation and affirmation have to finish on the trade date through straight-through processing, and there is less than a day to fix booking or settlement instruction errors.

That puts weight on the event backbone between order management, allocation, confirmation and settlement systems. Events must not be lost, must be replayable to investigate a break, and the platform needs out-of-hours cover because there is less time to recover from an overnight incident.

• Replay and reconciliation — Kafka retention and consumer group design so a post-trade service can re-read events after a fault.
• Ordering — Keys by account or instrument, or RabbitMQ super streams, so related events are processed in order.
• Lag you can see — Consumer lag alerting, so a stalled confirmation service shows up before the settlement deadline.
• Out-of-hours cover — 24x7 support with a 15-minute P1 response, and managed operation for teams that do not want the pager.

Order entry and matching run on specialised low-latency trading infrastructure outside a general-purpose broker. The brokers and caches we support carry the work around it: post-trade events, risk and position updates, and cached reference data for low-latency messaging reads. We support the platform your post-trade applications run on and do not run the applications.

Kafka support for post-trade platforms is on Kafka support

A multi-broker review for an online trading platform is in the trading platform assessment

Insurance: policy, claims and billing messaging

Insurers run long-lived policy platforms, so the messaging layer has to outlast several core-system changes. The work we do for them is modernizing IBM MQ without replacing the policy core, patching RabbitMQ without downtime and keeping claims and billing events moving. American National Insurance is the named example, and the sections below describe the migration and the patching case.

The insurance view, with its own questions and cases, is on messaging for insurers

Regulated messaging: audit trails, encryption, FIPS and change records

Auditors do not assess a message broker as a product. They ask whether access is controlled, traffic is encrypted, changes are recorded, vulnerabilities have a route to a fix and the platform survives a failure. The table maps those questions to what the brokers offer and what AceMQ adds. We help you gather the evidence. We do not certify your platform, and this page makes no certification claim.

The framework side is covered on our RabbitMQ compliance page, which maps broker configuration to the documented controls auditors working to SOC 2, ISO 27001, PCI DSS or HIPAA typically ask about. Your own compliance team, not AceMQ, decides what satisfies your framework.

For FIPS cryptography, see FIPSMQ, AceMQ's FIPS-compliant message broker

and for the options side by side, read FIPS RabbitMQ options compared

For broker audit readiness, see RabbitMQ compliance

DORA and PCI DSS evidence for the messaging layer

DORA, Regulation (EU) 2022/2554, has applied since 17 January 2025. It covers ICT risk management, reporting of major ICT incidents, resilience testing and the oversight of ICT third-party providers. PCI DSS v4.0.1 applies where a broker carries cardholder data, and its future-dated requirements became mandatory on 31 March 2025. For a bank's messaging layer both come down to evidence: a tested recovery path, an incident record, clear terms with the provider and a route to fix vulnerabilities.

We help you gather and produce the evidence. Whether it satisfies DORA, PCI DSS or your regulator is for your compliance team and auditors to decide, and this page makes no certification claim.

The programme view, across frameworks, is on compliance for messaging platforms

Message broker support for a bank starts at enterprise support

Frozen versions and change windows

Regulated change processes are slow on purpose. A version that passed validation stays in production until the next window, and that is where a broker falls out of community support. The options are an upgrade planned into a window, or security backports to the version you run.

• Extended support for older RabbitMQ — AceMQ backports fixes to the exact series you run. Critical CVEs are targeted at 72 hours, with actual turnaround depending on severity and the complexity of the backport. Support reaches back to RabbitMQ 3.8.x.
• Blue-green patching — For a regional insurance and member services provider on an old RabbitMQ series, AceMQ designed a blue-green deployment strategy so patching and migration could run with zero downtime, coordinated with the customer's middleware upgrade and a move to directory-based authentication.
• Changes inside your calendar — Under managed operation on your infrastructure, upgrades are planned on a published cadence and executed in your change windows.
• IBM MQ lifecycle — IBM publishes lifecycle dates by version. Our IBM MQ migration page lists them and explains the upgrade-or-move decision.

Extended support is described in RabbitMQ extended LTS support

and the patching case is in the insurance CVE patching use case

IBM MQ and mainframe modernization

IBM MQ is entrenched in financial services because it has earned the place. The reasons to move are usually licensing cost and the shape of newer workloads, and the constraint is legacy code and mainframe queues. A blanket move to one replacement tends to fail, so we classify each workload by messaging pattern, ordering needs and latency, and route it: RabbitMQ for transactional, routing-heavy and request and reply workloads, Kafka for event streaming and high-throughput append workloads.

American National Insurance, a named AceMQ customer, is the worked example. AceMQ led a phased IBM MQ to RabbitMQ migration there. Windows-based queues moved first, a roadmap covered the mainframe queues as a later phase, and the work was done under the customer's HIPAA requirements with a period of parallel operation and behavior validation before each cutover. American National also replaced a Kafka-based change data capture pipeline with standalone Debezium publishing to RabbitMQ.

The American National migration is described in the IBM MQ to RabbitMQ migration use case

and the change data capture case in the Debezium and RabbitMQ use case

The migration service is IBM MQ migration and alternatives

For the approach to financial services estates, read IBM MQ modernization for financial services

24x7 support and the four-stage ladder

Financial platforms run outside office hours, so cover has to as well. For RabbitMQ, Kafka and Redis or Valkey, AceMQ offers four stages of operational outsourcing, and regulated teams usually choose a stage by who is allowed to hold the pager and where the data may live.

IBM MQ and ActiveMQ estates are covered by support rather than the managed stages.

Start with RabbitMQ support

or see managed RabbitMQ services

For Kafka, see Kafka support

For the architecture decisions that come first, see event-driven architecture consulting

To check a running broker, book a RabbitMQ health check

or a Kafka health check

What this page does not claim

• No certification claims — AceMQ helps you gather and produce evidence for the messaging layer. Whether it satisfies your regulator or framework is for your compliance team and auditors.
• Named customers — American National is the named reference on this page. Other examples are anonymised, and details that could identify a customer are left out.
• No outcomes promised in advance — We do not quote throughput, availability or cost figures before seeing your workload.
• Application code stays yours — We design, review and test with your engineers. Your developers write the payment and trading logic.