SWIFT connectivity, messaging services, and the CSP
The Swift messaging services FIN, InterAct, and FileAct, the validation that guards them, and the Customer Security Programme that hardens every user's environment.
L0 Explain simply
Think of Swift not as a bank or a place money is kept, but as a very careful postal service used by banks to send each other instructions. Money does not travel through Swift; messages do, and those messages tell banks to move money that sits in their own accounts. Because these messages are so consequential, the postal service offers different ways to send them, suited to different needs. Some messages are single, urgent notes handed over one at a time and held safely until the receiver picks them up. Some are quick back-and-forth exchanges, like a short conversation. And some are large sacks of documents sent in bulk. Just as importantly, a careful postal service does not only worry about the letters in transit; it also worries about whether each sender's own mailroom is locked and trustworthy. Much of the effort, then, goes not just into carrying messages safely but into making sure every participant keeps their own doors secure.
L1 Core concepts
Swift offers several messaging services, each suited to a different job. FIN (Swift FIN messaging) is the classic store-and-forward service that carries structured MT (message type) messages, such as bank-to-bank funds transfers, one message at a time. Swift accepts, validates, and holds each FIN message, then delivers it to the receiver, so neither party need be online at the same moment. InterAct is a service for real-time, interactive exchange of individual messages, commonly the newer ISO 20022 MX messages used in modern market infrastructures. FileAct is for moving files and bulk data, and it is largely format-agnostic, so it can carry batches of instructions, statements, or reports that do not fit a single structured message. Choosing among them depends on whether the traffic is a single instruction, a live exchange, or a large file, and on which message standard is in use. Together they let Swift serve both older MT flows and newer structured ones.
L2 Practitioner view
A key strength of the FIN (Swift FIN messaging) service is that it does not simply carry whatever it is given; it validates messages before accepting them. Each field in an MT (message type) message has a defined format, and the network checks that the content fits. Beyond single fields, FIN applies network-validated rules: cross-field checks that confirm combinations of fields are consistent with each other, for instance that a code word matches the presence or absence of another field it governs. Fields are also marked as mandatory or optional, so the network can reject a message that omits something it must contain. A message that fails validation is rejected at the network rather than passed on, which stops many malformed instructions before they ever reach a receiver. This up-front discipline is one reason MT messages have been dependable for decades: the format is strict, the rules are published, and the network enforces them evenly for everyone, so a receiver can trust the shape of what arrives.
L3 Technical details
Reliable message carriage is not enough on its own, because the weakest point is often not the network but a user's own systems. If an attacker gains control of a bank's local Swift environment, they can try to submit fraudulent but perfectly well-formed instructions, which validation alone will not catch. To address this, Swift runs the Customer Security Programme (CSP). At its centre is the Customer Security Controls Framework (CSCF), which sets out security controls that users are expected to implement in their own environments, covering matters such as restricting access, protecting credentials, and detecting anomalous activity. Some controls are mandatory and some advisory, and users must attest annually to how far they comply. The programme reflects a simple truth: a shared network is only as trustworthy as its least secure participant. By requiring every user to meet a baseline and to declare their position each year, the CSP raises the floor for the whole community rather than leaving each institution to decide alone how much security is enough.
L4 Standards & sources
The annual attestation does more than discipline the attesting institution; it becomes information others can act on. Under the Customer Security Programme (CSP), a Swift user records its compliance with the Customer Security Controls Framework (CSCF), and counterparties can request and consult that attestation. This means a bank can factor a correspondent's declared security posture into its own risk decisions, so weak security carries a reputational and commercial cost, not merely a compliance one. It is a form of counterparty risk management layered on top of the technical controls. Two cautions for readers. First, an attestation is a declaration of controls in place, not a guarantee that no incident can occur, so it informs judgement rather than removing risk. Second, the specific controls, their mandatory or advisory status, and the attestation process are defined by Swift and updated over time, and the authoritative detail sits in the CSCF itself rather than in any summary. The enduring point is that message security and environment security are treated as one problem.
Sources & standards2
- Official requirement
Customer Security Programme (CSP) and Customer Security Controls Framework ↗ — Swift · Customer Security Programme, Customer Security Controls Framework, mandatory controls and annual attestation
The full Customer Security Controls Framework and detailed control descriptions sit behind a swift.com login.
- Official requirement
Swift Standards MT (annual standards releases) ↗ — Swift · Swift MT message standards, field formats and network-validated rules
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.
Sources for this topic3
- Official requirement
Customer Security Programme (CSP) and Customer Security Controls Framework ↗ — Swift · Customer Security Programme, Customer Security Controls Framework, mandatory controls and annual attestation
The full Customer Security Controls Framework and detailed control descriptions sit behind a swift.com login.
- Official requirement
Swift Standards MT (annual standards releases) ↗ — Swift · Swift MT message standards, field formats and network-validated rules
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.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
What this simplifies: The postal-service and mailroom analogies simplify Swift's services and security programme; the authoritative controls and message rules live in the Customer Security Controls Framework and the MT standards themselves.
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.
Deepest material on this page: L4 — Standards & sources. Where a topic stops short of implementation depth, that is a deliberate coverage decision, not an oversight — see coverage.