GLOBAL PAYMENTS KNOWLEDGEISO 20022 / SWIFT / SEPA / MT / MX

SWIFT / Learning brief

SWIFT messaging services: FIN, InterAct, and FileAct

Your notes

What this means in plain language

The three SWIFT messaging services — FIN for store-and-forward MT messaging, InterAct for real-time ISO 20022 exchanges, and FileAct for secure bulk file transfer — and when banks use each.

SWIFT (Society for Worldwide Interbank Financial Telecommunication) is not one channel but several. FIN is the long-established store-and-forward service that carries MT (Message Type) messages, including bank-to-bank funds transfers; the network holds each message and delivers it when the receiver is ready. InterAct carries structured messages in real time and is the path used for ISO 20022 MX (the newer XML-based standard) exchanges, where two parties expect a prompt response. FileAct moves files rather than single messages; it is format-agnostic, meaning it can carry bulk payment batches, reports, or statements regardless of their internal layout. Choosing among them depends on whether the traffic is a single instruction, an interactive exchange, or a large file, and whether it must be delivered immediately or simply reliably.

Understand the full idea, step by step

Ask how a bank "sends a SWIFT message" and you will get three honest but different answers, because SWIFT runs more than one messaging service — each shaped for a different kind of traffic. Getting them straight is the difference between building a flow on the right transport and quietly building it on the wrong one.

FINthe store-and-forward service that carries classic MT messages

FIN is the service most people mean by "a SWIFT message". It carries MT (Message Type) messages — the structured, tag-based instructions used for bank-to-bank transfers, confirmations, and much more. It is store-and-forward: the sender submits, SWIFT validates, stores, and forwards to the receiver when available. Each message is individually addressed, validated against published standards, and acknowledged, so the sender always knows the network accepted or rejected it. It is well matched to payment instructions — each transfer a self-contained order that must arrive exactly once.

InterActthe service for structured XML messages, real-time or store-and-forward

InterAct carries structured messages in either a real-time request-and-response pattern or store-and-forward. It is the service that transports much ISO 20022 traffic, whose MX messages are written in XML (Extensible Markup Language) and carry richer, more structured data than MT. Its real-time mode suits query-and-answer and time-sensitive settlement exchanges, where one party sends a request and receives a response in the same conversation.

FileActthe service that transfers whole files, not single messages

FileAct moves a file rather than one message, and it is format-agnostic: the file may hold a batch of payments, reports, statements, or reference data, and FileAct need not understand the contents to deliver them securely. That makes it the right tool for bulk, high-volume exchanges — thousands of records travelling as one unit. Like the others it can run store-and-forward, and it also offers a real-time mode where the file passes directly while both sides are connected.

Which service for which traffic
FINInterActFileAct
Unit of exchangeOne MT messageOne structured (XML) messageA whole file of records
Standard it mainly carriesMTISO 20022 MX and other XMLAny format — content-agnostic
Timing patternStore-and-forwardReal-time or store-and-forwardStore-and-forward or real-time
Typical jobA single cross-border payment instructionA real-time query/response or ISO 20022 exchangeAn overnight batch of payments or a large report

You may be wondering whether these three compete — is one of them the "new" one that replaces the others?

They are a toolkit, not rivals. As the industry migrates payment messaging to ISO 20022, traffic that once travelled as MT over FIN increasingly moves as MX over an InterAct-based service or as files over FileAct — but FIN still carries a large share of live payment instructions during the transition. A practitioner picks by the *shape* of the traffic: a self-contained instruction, a real-time exchange, or a bulk file. The exact service availability and profiles vary by institution and agreement.

WHAT IF — A team routes a bulk overnight batch of thousands of payments as individual FIN messages

What happens: The flow works but fits the transport badly — thousands of separate store-and-forward messages where a single file would do, adding load, cost, and reconciliation effort with no benefit.

How it is handled: The batch belongs on FileAct, which carries the whole file as one unit. Choosing the transport from the shape of the traffic — single instruction to FIN, real-time exchange to InterAct, bulk file to FileAct — avoids building a flow on the wrong service.

FOR NOW, REMEMBER

  • FIN is store-and-forward messaging for classic MT messages — the backbone for single payment instructions.
  • InterAct carries structured XML messages, real-time or store-and-forward, and transports much ISO 20022 MX traffic.
  • FileAct transfers whole files of any format, ideal for bulk and high-volume exchanges.
  • The three are a toolkit chosen by the shape of the traffic, not competitors — and MT-over-FIN volume is shifting toward MX as ISO 20022 spreads.

TRY IT YOURSELF

A market infrastructure needs Bank Alfa to send a query and get a structured answer back within the same exchange, using ISO 20022 messages. Which service fits the requirement?

FIN, because it is the service banks use for all SWIFT messaging.

Not this one — FIN is store-and-forward and carries MT messages — it does not provide a real-time request-and-response exchange, and it is not the channel for ISO 20022 MX traffic.

InterAct, whose real-time mode supports request-and-response and carries ISO 20022 messages.

Correct — Right. InterAct's real-time pattern gives the same-exchange query and answer, and it is the service that transports ISO 20022 MX — matching both parts of the requirement.

FileAct, because it moves data securely between the two parties.

Not this one — FileAct moves whole files, suited to bulk transfers — not a single real-time query-and-answer. It would be the wrong shape of transport for a live request-and-response exchange.

ISO 20022 payments needed their own lane over SWIFT. Next: FINplus — the store-and-forward service carrying ISO 20022 for cross-border payments under CBPR+ — and Browse, the human-in-the-loop web service.

KEEP GOING

Three things to remember

  1. 01

    FIN is store-and-forward MT messaging for individual instructions such as transfers.

  2. 02

    InterAct carries real-time structured messages, including ISO 20022 MX exchanges.

  3. 03

    FileAct moves bulk files of any format, such as batches, reports, and statements.

Where you would use this

USE CASE 01

A correspondent bank sends an individual funds transfer over FIN.

USE CASE 02

A market infrastructure exchanges real-time settlement messages over InterAct.

USE CASE 03

A corporate bank delivers an end-of-day statement file to a client over FileAct.

Put the idea into a real situation

Illustrative example: a fictional bank, Northgate Clearing, uses all three in one day. It sends 1 urgent transfer as an MT103 over FIN, receives an ISO 20022 status message over InterAct within 2 seconds of a real-time settlement request, and at 18:00 delivers a single FileAct file containing 4,200 batched direct-debit records to a partner institution. Each service fits the shape of the traffic it carries.

Evidence & review

REVIEWED 2026-07-13

SWIFT messaging services in general terms; service availability, profiles, and the pace of ISO 20022 migration vary by institution and agreement.

What this brief simplifies: Describes each service's primary role and typical fit; omits per-service technical profiles, subscription detail, and precise migration scope.

Sources for this brief4
  1. Market practice

    Swift products and servicesSwift · Messaging services: FIN, InterAct, FileAct

    Describes Swift's messaging, connectivity, global payments innovation, platform, and compliance services offered to member institutions. · Checked 2026-07-13

    Used for the public overview of product details documented behind swift.com.

  2. Official requirement

    Swift Standards MT (annual standards releases)Swift · MT messages carried over FIN

    Defines the MT message standards (including MT101, MT103, MT202/202 COV, and the MT9xx statement messages) exchanged over the Swift FIN network, maintained through annual standards releases. · Checked 2026-07-12

    Full field-level specifications live in the Swift Knowledge Centre User Handbook behind a swift.com login; content here relies on public summaries. Swift ended MT-to-ISO 20022 coexistence for in-scope cross-border payment instructions (for example MT103 and MT202) in November 2025; MT statement messages are being phased out on a separate timeline.

  3. Official requirement

    ISO 20022 Standards (Swift ISO 20022 adoption programme)Swift · ISO 20022 MX over InterAct-based services

    Describes the Swift community's adoption of ISO 20022 for cross-border payments and reporting, including the CBPR+ migration and the end of MT-MX coexistence. · Checked 2026-07-12

    Programme milestones change over time; the coexistence period for in-scope cross-border payment instructions ended in November 2025. Check swift.com for the current timeline.

  4. Simplified educational illustration

    Payments Signal editorial teaching modelsPayments Signal

    This site's own simplified teaching models. · Checked 2026-07-12

    Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.

Learn this properly

Related briefs

View SWIFT archive

SWIFT Universal Confirmation and gpi Services

Universal Confirmation asks every bank to confirm the fate of a payment — credited, returned, or rejected — feeding the gpi tracker. This piece walks through the gpi service variants and the Daily Validation Report as a detective control.

READ BRIEF