Banking was one of the first industries to adopt IBM MQ (formerly MQSeries) at scale because money movement cannot tolerate silent loss: a transfer initiated from mobile banking must either complete with an auditable record or fail with a reason the customer and regulators can understand. Modern banking estates still combine decades-old core ledgers on z/OS with cloud-native fraud engines and API gateways. IBM MQ sits between those tiers as the neutral buffer and security checkpoint. This tutorial explains a reference banking architecture—channel applications, hub queue manager, core and fraud consumers, request/reply for inquiries, batch ledger posting, z/OS RACF integration, and the operational signals that indicate a production incident on payment queues.
Channel applications include mobile apps, internet banking, branch teller systems (often CICS), and ATM switches. They validate format and limits, then use MQI to MQPUT a payment or account message. The put is usually persistent and often under syncpoint with a local authorization database so the channel record and the message commit together. If the put fails with 2035 (not authorized), the problem is OAM or CHLAUTH—not “MQ is down.” Beginners should trace the MCAUSER on the SVRCONN channel and the principal granted put authority on the target queue.
12345DEFINE QLOCAL('PAYMENTS.REQUEST') MAXDEPTH(500000) DEFPSIST(YES) + BOTHRESH(1000) BOQNAME('PAYMENTS.DLQ') BOTHRESH(5) DEFINE QLOCAL('PAYMENTS.REPLY') MAXDEPTH(100000) DEFPSIST(YES) * BOTHRESH on work queue — after N backouts, message moves to BOQNAME * DEFPSIST(YES) — messages survive QM restart (banking default for payments)
Large banks centralize definitions on a hub queue manager. Regional spokes—branch data centers or cloud regions—connect via sender-receiver channels. An application on a spoke puts to REMOTE or alias queue PAYMENTS.REQUEST that resolves to the hub local queue. This design lets security teams enforce TLS and CHLAUTH once at the hub edge while spokes remain simpler. Trade-off: hub failure affects many regions, so multi-instance queue managers or Native HA on the hub is standard for tier-1 payments traffic.
| Tier | Function | MQ pattern |
|---|---|---|
| Channel | Capture customer intent | Persistent put, often syncpoint |
| Fraud | Score and hold/release | Request/reply or one-way with status topic |
| Core | Post accounts, enforce limits | Work queue consumer, syncpoint with Db2 |
| GL batch | End-of-day aggregation | Drain deep queue overnight |
| Partner | Correspondent bank | Channel over DMZ, strict CHLAUTH |
Not every banking message is fire-and-forget. Balance inquiry and hold verification expect a response within seconds. The channel program puts a request with MsgId and sets ReplyToQ to a dedicated reply queue (often per instance or pooled). The core service GETs the request, processes, and PUTs the reply with CorrelId matching the request MsgId. The channel GETs the reply with a correlation match. Timeouts must be handled: if no reply arrives, the UI shows failure even though the request might still be on the work queue—operations correlate by MsgId in logs.
Fraud systems may consume a copy of payment messages from a pub/sub topic FIN.PAYMENT.CREATED while the critical path uses point-to-point for straight-through processing. Subscribers must be idempotent: the same payment might be seen twice after redelivery. Banking architectures store an idempotency key in the payload (end-to-end reference) and reject duplicates in the database. MQ does not deduplicate automatically; application design owns exactly-once business semantics on top of at-least-once delivery.
On z/OS, queue sharing groups allow multiple queue manager members to share queues in the coupling facility for availability. CICS transactions MQPUT to shared queues; batch jobs drain them in evening windows. RACF profiles govern who can connect, put, and get. The mainframe integration tutorial in this track expands CICS and QSG detail; here the key point is that banking MQ on z/OS is not an isolated island—it channels to distributed fraud and reporting hubs.
The teller window is the channel application: it accepts your deposit slip quickly. The back office is core banking: it posts to accounts when ready. The tray between them is the queue—slips pile up if the back office is slow, but they are not thrown away. Persistent messages are slips in a locked drawer that survive end of shift.
When you give money at the bank window, the worker puts your form in a box. Later someone in the back room takes forms from the box and puts the money in the right piggy banks. IBM MQ is the box that keeps forms safe until the back room is ready, even if the bank closes for lunch.
Label a diagram with channel, fraud, core, and GL batch; mark which queues are persistent.
Define BOTHRESH and BOQNAME for a payment work queue and explain what happens on the sixth backout.
Write a three-line runbook entry for “PAYMENTS.REQUEST depth above 50,000 for 15 minutes.”
1. Banking payment messages are usually:
2. When core banking is down, the channel tier can:
3. Request/reply in banking uses:
4. Poison payment messages should: