What Is SWIFT in T24?

At some point in your T24 career, you will be in a production support call and someone will say something like "the SWIFT MT103 is stuck in repair" or "the BIC is not recognised" or "we need to check the RMA." These phrases get thrown around with the casual confidence of someone who definitely knows what they mean. And maybe they do. But if you are new to SWIFT in T24, it all sounds like alphabet soup with a side of panic.

This article is the plain-English version. No assumed knowledge. Just what SWIFT is, how T24 handles it, and what actually happens when a payment goes from "sent" to "why is it still sitting in the outbox."

What SWIFT actually is

SWIFT — the Society for Worldwide Interbank Financial Telecommunication — is not a bank. It is a messaging network. Think of it as WhatsApp for banks, except the messages are highly structured, every character matters, and if you send the wrong thing, someone else's money ends up in the wrong country.

When Bank A wants to send money to Bank B, it does not just pick up the phone and ask. It sends a SWIFT message through the SWIFT network. The message contains everything needed: who is sending, who is receiving, how much, in what currency, and any instructions along the way. Bank B receives the message, processes it, and credits the beneficiary.

In T24, SWIFT integration means the system can generate these messages automatically when a payment is processed, send them out through the SWIFT network, and receive incoming messages from other banks to process inbound payments. It all happens without a human touching anything — until something goes wrong, at which point a human gets paged at 3am.

MT vs MX: the two languages of SWIFT

SWIFT messages come in two flavours, and T24 supports both. The difference matters because the industry is in the middle of a slow, painful migration from one to the other.

MT (FIN) messages — the old reliable

MT messages are the classic SWIFT format. They look like a block of text with numbered fields. An MT103 (customer credit transfer) might have field 50 for the ordering customer, field 59 for the beneficiary, field 32A for the amount and value date. It is compact, efficient, and has been the standard for decades.

The problem is that MT messages are limited. There is only so much information you can fit into those numbered fields. If you need to send additional remittance information or structured address details, you end up cramming things into fields they were not designed for, which is the SWIFT equivalent of using a shoehorn to fit a foot into a shoe that is two sizes too small.

MX (ISO 20022) messages — the new standard

MX messages are XML-based. They are more flexible, more structured, and can carry much more information. Instead of field 59 for the beneficiary, you get a full XML structure with name, address, account, identification, and anything else you might need.

The industry is moving to MX because regulators want more data on every payment. Anti-money laundering, sanctions screening, tax reporting — all of these require information that MT messages were never designed to carry. So MX is the future. Unfortunately, the future is arriving at different speeds in different countries, which means T24 has to handle both formats, sometimes for the same payment.

If you have ever wondered why a payment works fine for EUR but fails for USD, or why one correspondent bank accepts the message and another rejects it, the answer is often "MT vs MX" — one bank has upgraded, the other has not, and T24 is stuck in the middle trying to translate.

How SWIFT works in T24

T24 handles SWIFT messages through several modules, but the main one you need to know about is the DE (Delivery) module. DE is the post office of T24. It receives messages, formats them, checks them, and sends them out. It also receives incoming messages, validates them, and routes them to the right place.

Here is the simplified flow for an outbound payment:

You process a payment in T24
    ↓
T24 creates a SWIFT message (MT103 or pacs.008)
    ↓
DE formats the message and checks the BIC is valid
    ↓
DE checks the RMA (is this bank allowed to talk to us?)
    ↓
Message is sent to the SWIFT network
    ↓
SWIFT delivers it to the receiving bank
    ↓
Receiving bank processes it and credits the beneficiary

And for an inbound payment:

Sending bank sends a SWIFT message
    ↓
SWIFT network delivers it to T24
    ↓
DE receives it and validates the format
    ↓
DE checks the RMA (are we allowed to receive from this bank?)
    ↓
Message is routed to the right T24 module
    ↓
T24 processes the payment and credits the customer

In theory, this all happens in seconds. In practice, there are about a dozen things that can go wrong at each step, which is why SWIFT-related production incidents are a permanent fixture of banking IT.

BIC and RMA: the two things that block everything

Two concepts come up constantly in SWIFT troubleshooting. If you understand these two, you can diagnose 80% of SWIFT problems without calling anyone.

BIC — Bank Identifier Code

Every bank on the SWIFT network has a BIC — an 8 or 11 character code that identifies it uniquely. BARCGB22 is Barclays in London. CHASUS33 is JP Morgan in New York. The BIC is how T24 knows which bank to send the message to.

T24 stores BIC information in the DE.BIC application. If a BIC is not in the directory, or if the directory is outdated, T24 cannot send the message. This is surprisingly common — banks merge, BICs change, and the directory does not always get updated in time.

The BIC directory is maintained by SWIFT and banks are supposed to load it regularly using DE.BIC.LOAD. If your bank has not done this in six months, the directory is wrong, and payments are failing silently.

RMA — Relationship Management Application

RMA is SWIFT's way of saying "we do not accept messages from random banks." Before T24 will process a message from another bank, it checks the RMA to see if there is an agreement in place. If there is no RMA, or the RMA has expired, the message is rejected.

RMA is configured in DE.RMA. Each record specifies which BIC is allowed to send which message types. If a new correspondent relationship is set up but nobody creates the RMA record, every payment from that bank gets rejected with an error that looks like a network problem but is actually a configuration problem.

The number of times a production incident has been caused by "someone forgot to set up the RMA" is not zero. It is not even close to zero.

SWIFT GPI — tracking your payment like a parcel

Before GPI (Global Payments Innovation), sending a SWIFT payment was like dropping a letter in a postbox. You knew when you sent it, and you hoped it arrived, but you had no way of tracking it along the way. If the receiving bank said "we never got it," you had no proof either way.

GPI changed this. Every GPI payment gets a unique tracking reference called a UETR (Unique End-to-End Transaction Reference). Think of it as a tracking number for a parcel. You can see when the payment left your bank, when it arrived at the correspondent bank, and when it reached the destination. If it gets stuck, you know exactly where.

T24 supports GPI through the PI.GPI.TRACKER application, which stores tracking events for each payment. Banks that have adopted GPI can offer their customers real-time payment tracking, which is a nice feature until you realise it also means customers can see exactly when your system failed to send their payment on time.

What goes wrong and why

SWIFT in T24 is reliable when everything is configured correctly. The problem is that "everything configured correctly" is a high bar. Here are the most common failures, in order of how often they happen:

1. BIC not found

The BIC in the payment does not exist in the T24 directory. Either the BIC is wrong, or the directory is outdated. Check DE.BIC first.

2. RMA not authorised

The sending or receiving bank does not have a valid RMA record. This is almost always a configuration gap — someone set up a new correspondent relationship but forgot the RMA.

3. Validation error

The message does not match the SWIFT format specification. A field is missing, a field is too long, or the structure is wrong. T24 validates messages before sending them, but sometimes the validation rules themselves are misconfigured.

4. Network error

The connection to the SWIFT network is down. This is rare but spectacular when it happens, because it affects every payment, not just one.

5. Duplicate message

The same UETR or reference has already been processed. This happens when a retry mechanism sends the same message twice. T24 rejects the duplicate, which is correct behaviour, but the sending system may not realise it is sending duplicates.

The common thread across all of these is that the error message T24 gives you is usually technically correct but completely unhelpful. "BIC not found" could mean the BIC is wrong, the directory is outdated, the BIC is valid but not loaded, or the BIC format is incorrect. The error is the same. The fix is different each time.

The repair queue — where payments go to wait

When a SWIFT message fails validation or processing, it ends up in the repair queue. This is a T24 application called PP.REPAIR (or DE.REPAIRdepending on the module). Think of it as the waiting room for payments that could not make it through.

A support analyst looks at the failed message, figures out what went wrong, fixes it, and resubmits it. In theory this takes minutes. In practice, the repair queue is where payments go to be forgotten about until someone notices that a customer's money has not arrived and starts asking questions.

T24 also has auto-repair rules in PP.AUTO.REPAIR.INSTANCE. These allow the system to automatically fix certain types of errors without human intervention. If the error is something simple like a missing field that can be defaulted, auto-repair handles it. If the error is something complex like "the beneficiary account number does not match the beneficiary name," that goes to a human. Or, more accurately, it goes to the repair queue where it waits for a human to notice it.

The big picture

SWIFT in T24 is a complex system, but the fundamentals are straightforward. There is a message format (MT or MX). There is a directory of banks (BIC). There is a permission system (RMA). There is a tracking system (GPI). And there is a repair queue for when things go wrong.

Most SWIFT problems in production come down to one of three things: a missing or outdated BIC, a missing or expired RMA, or a message format that does not match what the receiving bank expects. If you check those three things first, you will solve the problem faster than the person who starts by blaming the network.

And if you ever find yourself in a 2am support call where someone is asking why a SWIFT payment is stuck, remember: the BIC directory was probably not updated, the RMA was probably not set up, and the person who was supposed to do it is probably asleep. That person might even be you.

Common SWIFT problems in T24

MT103 stuck in the repair queue

The most common SWIFT support issue. An MT103 payment message is generated by T24 but ends up in the repair queue instead of being sent. The cause is almost always a field validation failure — a missing BIC, an invalid currency code, or a formatting issue in the message body. Check theDE.REPAIR record for the specific error before touching anything else.

BIC and RMA issues

Every SWIFT message requires a valid BIC (Bank Identifier Code) for the sender and receiver. If the BIC is missing, incorrect, or not authorised via RMA (Relationship Management Application), the message will not be accepted by the SWIFT network. In T24, RMA validation happens in theDE.MESSAGE delivery module — check the RMA status before assuming the message format is wrong.

DE.MESSAGE and the delivery module

T24 uses the DE.MESSAGE application to manage SWIFT message delivery. This is where messages are queued, formatted, and sent. If a message is stuck, check DE.MESSAGE for the delivery status. Common issues include network connectivity problems, SWIFT session failures, and incorrect destination addresses.

Why MX matters now

The SWIFT MT to MX (ISO 20022) migration is already underway. MX messages use XML format instead of the fixed-width MT format. T24 supports both, but the transition requires configuration changes in the message type definitions and delivery setup. Banks still running MT-only configurations will need to plan the upgrade before the SWIFT deadline.

Frequently asked questions about SWIFT in T24

What is SWIFT in T24?

SWIFT is the global messaging network that banks use to communicate with each other. In T24, SWIFT messages handle payment instructions, confirmations, statements, and other interbank communications through dedicated modules like SWIFT.INTERFACE and SWIFT.MESSAGES.

What is the difference between MT and MX messages?

MT (Message Type) is the legacy SWIFT format using fixed field definitions and character-based encoding. MX is the newer ISO 20022 XML-based format that supports richer data structures. The industry is migrating from MT to MX, and T24 teams need to handle both during the transition.

Why do SWIFT payments get stuck in a repair queue?

Payments land in the repair queue when T24 cannot process them automatically — usually due to missing or invalid data, format mismatches, validation failures, or configuration issues in the SWIFT interface. Each repair requires manual intervention to correct and resubmit.