SWIFT CSCF: 2026 Deadline, Controls, and Assessment Rules

SWIFT CSCF attestation requirements oblige every institution connected to the SWIFT network to confirm, once a year, that it meets the mandatory security controls in the Customer Security Controls Framework for its architecture type, backed by an independent assessment and submitted through SWIFT’s KYC-Security Attestation portal. For the 2026 cycle, the submission window runs from July through December 31, 2026, and the framework contains 32 controls in total: 25 mandatory and 7 advisory.¹²

The 2026 Deadline and a Workable Timeline

CSCF v2026 was published in mid-2025, and attestations against its requirements are accepted from July 2026 through December 31, 2026.¹ Six months looks comfortable on paper. It usually isn’t.

The independent assessment alone can take several weeks, and any gaps the assessor flags need to be closed before you can submit a clean attestation. Working backwards from December 31, a sensible plan finishes internal evidence gathering by late summer, books the independent assessment for early fall, uses October and November for remediation, and treats December as a submission buffer rather than a deadline sprint.

Which Controls Apply to You

The controls you need to attest against depend on your architecture type, which describes how your institution connects to the SWIFT network. Picking the wrong type means attesting against the wrong control set, so settle this before you start pulling evidence. SWIFT recognizes five types:³

A1: You own and operate both the messaging interface and the communication interface. The full set of mandatory controls applies.
A2: You own the messaging interface but rely on a service provider or SWIFT for the communication interface. The same mandatory controls apply, with minor scope differences.
A3: You use a SWIFT connector in your environment to communicate application-to-application with an interface hosted by a provider or by SWIFT cloud services. You do not own a messaging or communication interface. Controls match A1 and A2 except that Control 6.3 (Database Integrity) does not apply.
A4: You have no SWIFT-specific interface but run a server, middleware, or API connector in your environment that connects to a service provider’s SWIFT infrastructure. Fewer controls apply than A1 to A3.
B: You have no local SWIFT footprint at all and access the service entirely through a provider’s interface or API. The fewest controls apply.

If you operate backup or disaster recovery environments alongside production, you must attest for the most encompassing architecture type that covers all of them.³

Watch Your Architecture Type for 2026

Customer client connectors are now mandatory in-scope components across 14 controls in CSCF v2026. If you previously attested as Type B because you had no local SWIFT infrastructure, but you reach your service bureau through a client connector such as an API consumer, middleware client, or file transfer application, you may now need to attest as Type A4 instead.⁴

The other change worth checking early is Control 2.4A, Back Office Data Flow Security. It has moved from advisory to mandatory, which means you now have to identify, document, and protect data flows between your SWIFT secure zone and back-office systems. The mandatory scope covers bridging servers between the secure zone and back-office first hops, flows between bridging servers, and any new direct flows introduced between the secure zone and back-office systems. Legacy direct exchanges between back-office first hops and the secure zone remain advisory for now, with a tentative mandatory date of 2028.⁴

Mandatory Versus Advisory

Of the 32 controls in CSCF v2026, 25 are mandatory and 7 are advisory. Mandatory controls are non-negotiable for every participant covered by them. Advisory controls are recommended practices that do not currently affect your compliance status, but SWIFT reclassifies advisory controls as mandatory in later versions on a regular cycle. Treating today’s advisory controls as tomorrow’s requirements, and budgeting accordingly, avoids an unpleasant surprise when the next framework drops.²

Evidence to Pull Together Before the Assessment

Your technical teams need to assemble proof that each mandatory requirement is actually met before anyone sits down to assess it. Start with system architecture diagrams that clearly define the boundaries of your secure zone, the area where SWIFT messaging components live and which is logically separated from the rest of your network.

Build a full inventory of what sits inside that zone: messaging interfaces, communication interfaces, connectors, operator workstations, and any jump servers used for administrative access. For 2026, include customer client connectors where your architecture type requires it.

Specific controls call for specific evidence:⁴

For Control 4.2 (multi-factor authentication), proof that every interactive user accessing SWIFT-related applications and operating system accounts authenticates with more than one factor.
For Control 6.4 (logging and monitoring), evidence that your systems capture command-line history for privileged accounts, application and OS logs flagging abnormal behavior such as after-hours activity or failed logins, firewall logs, and database logs where available.
For Control 2.2 (security updates), demonstration that hardware and software in the secure zone is within the vendor’s support lifecycle, running mandatory software updates, and receiving timely security patches based on a documented risk assessment.

SWIFT provides self-assessment templates through its user portal with fields for environment details and the dates each control was last verified. Filling these out thoroughly before the assessor arrives avoids the churn of incomplete documentation requests mid-review.

Rules for the Independent Assessment

Since 2021, every SWIFT user has had to support its annual attestation with an independent assessment. The person doing the assessing cannot be someone who designed or implemented the controls being tested. You have two options: an internal team such as internal audit or compliance, provided it has cybersecurity expertise and reports independently of IT operations, or an external cybersecurity firm.⁵

Either way, the lead assessor must hold at least one industry-recognized cybersecurity certification. SWIFT does not publish a definitive list but gives examples of what qualifies:⁶

Certified Information Systems Security Professional (CISSP)
Certified Information Systems Auditor (CISA)
Certified Information Security Manager (CISM)
PCI Qualified Security Assessor (QSA)
ISO 27001 Lead Auditor
SANS GIAC certifications

Audit-only credentials that do not cover cybersecurity do not meet the bar. Local-market certifications in the local language are acceptable where they offer equivalent rigor.⁶ The assessor reviews documentation, tests whether controls actually function as described, and records the results. Those records must be available if SWIFT later selects your institution for a follow-up review.

Submitting Through the KYC-Security Attestation Portal

Once the independent assessment is complete, your authorized security officer logs into the KYC-Security Attestation application and enters the findings. The portal walks through each applicable control and requires a status for each one: fully compliant, partially compliant, or not applicable. After every entry is in, the officer signs electronically and submits.¹

The portal also includes a sharing feature that lets you control which counterparties can see your attestation status. Correspondent banks and payment partners routinely check their counterparties’ compliance standing, so an up-to-date, fully compliant attestation becomes part of how other institutions assess you.

What Happens If You Miss It or Fail

SWIFT does not impose monetary fines directly. What it does do is report institutions that lack a valid attestation, fail to submit one, or do not meet mandatory controls to their local supervisory authorities.³ After that, consequences depend on jurisdiction and can include targeted cybersecurity audits, remediation mandates with fixed deadlines, and financial penalties set by the regulator rather than SWIFT.

For prolonged or serious non-compliance, SWIFT retains the authority to restrict or suspend network access. For a bank that depends on SWIFT for cross-border payments, trade finance, and treasury operations, even a temporary loss of access can freeze client transactions and create liquidity problems. Because counterparties can see your attestation status through the portal, they adjust their risk appetite accordingly, which can translate into heavier due diligence, reduced transaction volumes, or terminated correspondent relationships.¹

1
SWIFT. Submit KYC-Security Attestation
2
SWIFT. Customer Security Controls Framework v2026
3
SWIFT. Customer Security Controls Framework v2024
4
SWIFT. Customer Security Controls Framework v2026
5
SWIFT. Perform an Independent Assessment
6
SWIFT. Independent Assessment Framework