Most large banks have a team, often literally called Middleware, that almost no interview-preparation material describes. It owns the software that sits between applications — the layer that lets one program hand a request, a message or a file to another without either of them knowing how the other works, where it runs, or whether it is awake.

The easiest way to picture it is a building. The applications are the offices. Middleware is the reception desk, the internal post room and the loading bay: nobody visits the building to admire them, the building does not function without them, and when one of them stops, every office discovers at once how much it depended on something it never thought about.

Everything a middleware team runs falls into one of three families, and the difference between them is not the technology — it is what moves, and whether anyone is waiting for it.

Asynchronous is the word that separates the second family from the first. In a synchronous call the caller stops and waits for an answer, like a phone call. In an asynchronous exchange the sender drops the message off and carries on, like posting a letter — which is only safe if something guarantees the letter arrives. Providing that guarantee is most of what messaging software is for.

Two terms from the diagram, since they recur throughout the section. SFTP is the SSH File Transfer Protocol — file transfer carried inside an encrypted Secure Shell (SSH) connection. MFT, managed file transfer, is the software layer on top of protocols like SFTP that adds what a bank actually needs: guaranteed delivery, restart after failure, encryption at rest, an audit trail and scheduling.

Two things get called middleware and are covered elsewhere on this site. API gateways — the front door for application programming interfaces (APIs), which handle authentication and rate limits for other programs — are in APIs, webhooks and MCP (the Model Context Protocol, which lets AI agents call tools). Integration platforms, historically called an enterprise service bus (ESB), such as IBM App Connect or MuleSoft, transform and route data between systems; they usually sit on top of the messaging layer described here rather than replacing it.

• Decades of systems that cannot call each other directly. A typical large bank runs a core ledger designed in the 1980s or 1990s, channel systems from the 2000s and mobile services from last year. Middleware is the translation and buffering layer that lets them coexist without each knowing the others’ formats, speeds or opening hours.
• Guarantees the business requires. A payment instruction must arrive exactly once even if a network drops mid-transfer. That is a property of the middleware, not of either application — which is why the middleware is audited.
• Vendors certify it. Core banking packages are certified against specific application servers and message brokers; Temenos’s published architecture material for its Transact core has long listed IBM WebSphere, Oracle WebLogic and Red Hat JBoss as supported application servers. The bank’s choice is often the vendor’s choice.
• The networks the bank joins define the interface. SWIFT, the global interbank messaging network, documents an adaptor through which a bank’s back office exchanges messages with its SWIFT gateway over IBM MQ queues. Payment schemes such as the UK’s Bacs and the US ACH network accept bulk payments as files in fixed formats. The bank does not get to choose these.
• Evidence. When a regulator or an auditor asks whether an instruction was received, when, and by whom, the answer usually comes from middleware logs.

The team’s work splits into five streams, and interviews probe all five:

Common job titles: Middleware Engineer, MQ Administrator, WebSphere or WebLogic Administrator, Integration Engineer, Kafka Platform Engineer, MFT Engineer. A great deal of this work is outsourced — the only middleware titles in our corpus are an “Integration Engineer” and a “MuleSoft Administrator” at Kyndryl, the infrastructure-services company that runs IT estates for large enterprises, banks among them.

Each family runs from first principles to the level an interview for a senior role will test: what it is and why it exists, the real flows in a bank, the products on the market, the infrastructure under them, how licensing works and what it costs, and finally a comparison of the products. The prices are list prices observed in September 2026, dated as such — a bank pays less after negotiation, but the metric a product is charged on matters more than the number, and the metric is what interviewers ask about.

• “Walk me through what happens when a customer’s payment leaves the mobile app.”
• “Why would you put a queue between two systems rather than have one call the other?”
• “What does ‘exactly once’ mean — and which component actually guarantees it?”
• “A queue’s depth is climbing. What do you check, in what order?”
• “How do you patch an application-server cluster without an outage?”
• “A partner’s file did not arrive by the cut-off. What happens next, and who decides?”
• “How is IBM MQ licensed, and what is the trap in sub-capacity licensing?”
• “When would you choose Kafka over IBM MQ — and when would you not?”

Every one of those is answered somewhere in the chapters that follow.