Key insights
- CSCF v2026 already moved the perimeter, bringing customer client connectors (such as API endpoints, middleware and file transfer clients) into the scope of 14 controls, depending on architecture type
- CSCF v2027 carries the expanded scope forward with 32 controls, 26 of them mandatory, ahead of the July to December 2027 attestation window
- Architecture classifications that predate v2026 may need reassessment where customer client connectors or other scope-changing factors are present; assessors will review the second expanded-scope cycle
- A practical security principle for the expanded perimeter is to inspect, sanitize and control files and data flows before they reach critical payment infrastructure
- Inspection points across those flows can generate useful evidence for logging, monitoring and attestation, although compliance remains the institution’s responsibility
Preparing for the 2027 CSCF Assessment
Most Swift-connected institutions can draw their Secure Zone from memory: the messaging interface, the jump servers, the hardened segment where payment traffic lives. That’s some of the best-defended ground in the organization. CSCF v2027 asks how well defended everything that leads into it is.
The biggest change has already happened. CSCF v2026, published in July 2025, made Control 2.4, Back-Office Data Flow Security, mandatory in a phased rollout and brought customer client connectors into the scope of 14 controls.
Legacy direct back-office data exchanges remain advisory for now, with 2028 tentatively indicated for a future mandatory transition. The current framework counts 32 security controls across seven principles, 26 of them mandatory, and the expanded scope carries forward into the 2027 cycle. CSCF v2027, published in July 2026, adds no new mandatory controls but brings the Secrets and Keys Vault (SKV) into scope across most of them. Advisory controls remain recommended practice that may become mandatory in later versions. Institutions are attesting against the expanded scope for the first time between July and December 2026, and the v2027 attestation window follows from July to December 2027, supported by independent assessment.
If your architecture classification still predates v2026, reassess it now, particularly if customer client connectors, external file flows, or new integration paths have been introduced since the last assessment. Teams whose first expanded-scope attestation is coming together through improvisation face a 2027 in which assessors expect the work behind it to look deliberate. Either way, the question is whether your security architecture is ready for what now sits beyond the Secure Zone.
Customer client connectors and the expanded scope
A payment environment rarely gets attacked through its strongest wall. Files and data reach Swift-related systems through customer portals, partner uploads, managed file transfer platforms, middleware queues, API integrations, and removable media carried into the data center. Each of those channels can move malicious or untrusted content toward infrastructure that older architecture reviews classified as safely out of scope.
The framework now treats these paths as part of the relevant security architecture. Customer client connectors sit in scope by name: API endpoints, middleware and file transfer clients, whether they run on servers or client endpoints. The scrutiny extends into the software itself, from security updates and vulnerability scanning to software integrity, putting the code of in-house connectors under the same examination as the files they carry.
If your architecture classification predates v2026, components you once treated as out of scope (a customer-facing upload service, an integration bus or a file transfer server) may need reassessment, particularly where they use or constitute a customer client connector.
Our Swift infographic maps these entry points on a single page.
For security leadership, the stakes compress into two scenarios. A malicious file that reaches payment infrastructure threatens the availability of the payments business itself, and a scope gap discovered during assessment becomes a documented finding with board visibility. Either outcome costs more than the reassessment that prevents it.
File security belongs in your architecture review
Nearly every channel the expanded scope covers exists to move files or structured data: uploads from customers and partners, batch transfers between institutions, attachments crossing middleware, and files carried across API boundaries. A single antivirus engine at the network edge was built for a narrower problem than this.
That makes file security an architecture decision. A practical principle is to inspect, sanitize and control files and data flows before they reach critical payment infrastructure, while ensuring that the controls applied are appropriate to each flow and its risk.
Inspecting files before they reach payment systems
A partner uploads an invoice batch through your customer portal. The file lands on a managed file transfer platform, a middleware queue picks it up, an integration service reformats the contents, and the output reaches an application with a route into Swift-connected systems. Four hops separate an external file from critical payment infrastructure, and in many institutions each hop trusts the one before it.
Applying the inspect, sanitize and control principle means placing a specific control at each hop. MetaDefender™ Core and MetaDefender ICAP Server scan files uploaded through customer-facing web applications, through REST API or ICAP integration. MetaDefender Managed File Transfer inspects content moving between back-office and Swift-related systems, supporting Control 2.4, Back-Office Data Flow Security.
Both route files through Metascan™ Multiscanning, more than 30 anti-malware engines scanning in parallel. That multi-engine scanning supports Control 6.1, Malware Protection, detecting known malicious content with higher accuracy than any single engine. Deep CDR™ Technology then sanitizes and regenerates each supported file, removing embedded active content before the file travels further. Suspicious files go to Adaptive Sandbox, where emulation-based analysis helps catch evasive and zero-day threats, supporting the advisory Control 6.5A, Intrusion Detection.
The same treatment extends to the storage repositories where backups and extracts land, with Proactive DLP™ checking files at rest for sensitive content. It also covers removable media and transient devices, which MetaDefender Kiosk and MetaDefender Drive scan and sanitize at a checkpoint before entry, supporting Control 3.1, Physical Security.
For in-house connector software, MetaDefender Software Supply Chain scans packages and dependencies for vulnerabilities and malicious components before deployment, supporting Controls 2.2, Security Updates; 2.7, Vulnerability Scanning; and 6.2, Software Integrity.
The result is one prevention layer applied consistently across the file channels routed through it, positioned upstream of the systems it exists to protect.
Inspection records that support your assessment
When the 2027 window opens in July, assessors will review the second attestation cycle under the expanded scope, and evidence that controls exist and operate effectively will carry more weight than declared intentions.
Inspection points across your file and data flows can generate useful evidence: inspection events, audit trails forwarded to your SIEM, and policy-enforcement records documenting how content is examined on its way toward payment systems. That evidence supports Control 6.4, Logging and Monitoring, and the CSCF attestation itself.
Compliance remains the institution's own responsibility, and assessors judge the architecture as a whole. What this work produces is a defensible answer to the assessor's central question: what can reach your payment infrastructure, and what happens to it on the way?
Three questions for your architecture team
Three questions make a useful first pass ahead of the 2027 window:
- Which external file and data flows can ultimately reach your payment infrastructure?
- How are files inspected before they enter Swift-related workflows?
- Does the expanded CSCF scope change your current architecture classification or controls?
Our SWIFT CSCF v2027 datasheet condenses the expanded scope, the affected infrastructure and the relevant preventive controls into a few pages you can share with architecture and GRC teams.
Download the SWIFT CSCF v2027 datasheet
If you would rather walk through your own environment, chat with an OPSWAT expert and bring your current architecture classification with you.
