SWIFT CSP for service bureau users: what you still owe

Does a SWIFT CSP service bureau user still need its own attestation?

Yes. Swift says that most of the implementation for a user connected through a service bureau, L2BA or Business Connect provider applies to the provider and is covered by a specific Swift audit, but the user must still implement controls for its own footprint, including its connectivity to the provider. The user also attests each year, and every attestation must be supported by an independent assessment. Outsourcing the connection does not outsource the attestation.

How much work remains depends on the architecture type that applies to your connection, which Swift determines through its architecture decision tree. The controls in scope follow that type, so the answer differs by connection model and by how much of the messaging footprint sits in your own environment, such as local operator workstations, interfaces, credentials and access paths you control. Read the general, product-agnostic controls before you scope anything, then confirm with the provider in writing which parts of the footprint it covers and which parts remain yours. Ask it for the scope of its own Swift audit so you can see where the two sets of responsibilities meet.

Attestation timing does not change with the connection model. Attest no later than 31 December and re-attest at least annually between July and December, and new joiners must attest before going live on the Swift network. You own your controls and your attestation. An independent assessor, whether internal or external, tests your footprint and supports the attestation. A consultant can prepare systems and evidence, but only the independent assessor's work supports the attestation that you submit.

Which parts of the footprint stay with the user

A service bureau or connectivity provider runs most of the Swift interface, but the Swift user still owns everything on its side of the link. The cards below cover the components that stay in the user's hands, and the exact set depends on the architecture type, so confirm each item against Swift's controls for that type. The organization owns every control, even where a provider operates part of the stack.

The connectivity link to the provider

The path between your network and the provider's Swift access point is part of your footprint. Your team decides how that link is routed, which hosts can reach it, and how traffic is restricted and monitored on your side. Check that you can show the assessor the boundary of your own environment, the firewall rules and network segments that define it, and who approved each change. Confirm the link design against the controls for your architecture type with Swift's guidance.

Local systems and operator access

Your workstations, jump hosts and any application servers that send or receive Swift messages stay under your administration. Verify that these systems are hardened, patched and limited to the people who need them to operate Swift-related tasks. Ask your provider which of these systems it expects you to manage, because an unclear split is a common source of assessment findings.

Credentials and privileged identities

Accounts that log into the provider's portal, administer your local connector, or approve payments remain yours to issue, review and revoke. Maintain a current list of who holds each privileged role, remove access when people change jobs, and require strong authentication for administrative actions. An illustrative check: if a departed administrator's account still works on the provider's portal, the control has failed on your side regardless of the provider's own audit.

Segregation from other environments

Systems used for Swift activity should be separated from general office IT and development networks so that a compromise elsewhere cannot reach them directly. Document the segregation design, the rules that enforce it and the testing that proves it works. Your assessor will look for evidence that the boundary holds in practice, not only in the diagram.

Monitoring and incident response

You need to detect suspicious activity on your own systems and connections and respond to it, even when the provider runs the central monitoring. Define who receives alerts from your logs, how quickly they are reviewed, and how an incident affecting your side is escalated to the provider and to Swift. Test the procedure at least once so the response plan reflects how your team actually works.

Records the assessor will request

An independent assessor needs evidence that each control on your side operates, not only that it is designed. Keep access reviews, change records, network configuration exports, patch reports, incident logs and the agreement with your provider that sets out responsibilities. Store these records so that they can be produced for the assessment period and reconciled with the attestation you submit in the KYC-SA application.

Who owns each duty when a provider carries the connection

Even when a service bureau, L2BA or Business Connect provider carries most of the connection, your organization still owns the controls for its own footprint, including the link between your systems and the provider. Swift's guidance is that the user implements controls for its own environment and its connectivity to the provider, and that the controls in scope depend on the architecture type that applies to you. Your organization remains accountable for the attestation it submits, whoever helped prepare the evidence.

Architecture decision: Determine which of the five architecture types applies to you using Swift's architecture decision tree, and record why.
Footprint controls: Implement and operate the in-scope controls for your own systems, users, credentials and network paths to the provider.
Provider evidence: Obtain and file the provider's current evidence and confirm it covers the services you actually use.
Attestation submission: Submit the KYC-SA attestation yourself, supported by an independent assessment, no later than 31 December.
Records and renewal: Keep the records the assessor needs and re-attest at least annually.

Before you rely on any provider, confirm which controls sit with you and which sit with it, and put that split in writing.

Why the architecture decision comes first for provider users

The architecture type decides which CSCF controls apply to you, so a Swift user that connects through a service bureau, L2BA or Business Connect provider must settle its architecture type before it plans implementation, gap work or assessment scope. Swift says the controls in scope depend on how a user connects to Swift, and it provides an architecture decision tree that maps the five types, A1, A2, A3, A4 and B, to connection models. Run that tree against your own connectivity to the provider, record the answer and the reasons, and have the owner of the connection sign it off before anyone writes a project plan.

The most common error is to pick the type from the provider's description of its service instead of from your own connection. A provider may describe its platform as a hosted Swift service, but the type that applies to you depends on what you run, host and operate on your side, including the interface you use to reach the provider. Reading the provider's marketing summary, or copying the type a peer bank uses, can put you in the wrong control set. Ask the provider for its own architecture type and for a written description of the components it covers, then compare that with your footprint. Where the two do not line up, treat the gap as a finding to resolve, not as a detail to smooth over.

Re-check the decision whenever the connection model changes. A new provider, a move to a different connectivity product, a new messaging interface, a change in where systems are hosted or a shift in who administers the link can each change the applicable type. Make the re-check part of change management, so that a change to the connection triggers a fresh architecture decision before go-live. Separately, all users must read the CSCF's general, product-agnostic controls before implementing anything, because those controls apply regardless of type. Confirm the current version and its applicability through the Swift CSP controls page before you start.

How the yearly attestation cycle runs for a provider user

The sequence takes a provider user from confirming how it connects to Swift to a submitted KYC-SA attestation that an independent assessment supports. Each phase leaves a record the next phase depends on.

Confirm the connection and architecture type
Start by recording how the organization reaches Swift through its service bureau, L2BA or Business Connect provider, and work through Swift's architecture decision tree to determine which of the five architecture types applies. The team owns this step, with input from whoever holds the provider contract and the network diagram. The output is a signed architecture decision record that names the type and the provider, and that the assessor can trace back to the connectivity arrangement.
Read the general controls before scoping
Before any implementation work, the security, compliance and operations leads read the CSCF's general, product-agnostic controls, which Swift says every user must read. The purpose is to understand which obligations stay with the user even when the provider runs most of the Swift infrastructure. The output is a reading log or briefing note, signed by the control owners, that lists the controls each owner accepts responsibility for.
Scope and gap-check the own footprint
Map the systems the user operates that sit in its own footprint, including its connection to the provider, its local access points, credentials and administrators, and compare the current state with each in-scope control. Ask the provider for its Swift audit summary so the team knows which obligations it already covers, and confirm the boundary in writing. The output is a scoping record and a gap register with an owner and an action for each open item.
Implement the in-scope controls
Close the gaps on the user's own footprint, which typically covers internet restriction, local access, identity and privilege management, monitoring and incident response for the user's side of the connection. Advisory controls that Swift may later make mandatory should be planned at the same time. The output is a control evidence file for each in-scope control, showing configuration, procedures, access records and test results that an assessor can sample.
Arrange the independent assessment
Choose an internal assessor from a second or third line function, such as internal audit, or an external assessment provider, and agree the scope in writing. Swift's Independent Assessment Framework requires the Community Standard Assessment every year, so the assessor must be able to test the user's own footprint against the in-scope controls. The output is a signed independent assessment report that covers the user's scope and states its findings and any remediation items.
Submit the KYC-SA attestation
Using the signed assessment, an authorized officer completes the KYC Security Attestation in the KYC-SA application, declaring compliance with the mandatory controls for the user's architecture type and disclosing any open remediation. Attestation must be submitted no later than 31 December, and users re-attest at least annually between July and December. The output is a submitted attestation and a retained copy, with the supporting assessment filed for the next cycle.
Attest before going live as a new joiner
A new joiner must attest before it goes live on the Swift network, so the same sequence runs ahead of go-live rather than at the year-end deadline. Confirm the connection, scope the footprint, implement, assess and submit before any production traffic flows. The output is an attestation on file in KYC-SA that predates the go-live date, which the organization can show to its supervisors and counterparties.

How provider users end up reported to their supervisors

Swift can report a user to its supervisor for any of five reasons, and a user connecting through a provider can trigger each one without noticing. The cards below cover each trigger, how it typically happens in a provider setting, and what to check in your own environment and contracts.

No valid attestation

Your KYC-SA attestation is the record Swift reads, and it must be submitted no later than 31 December and re-attested at least annually between July and December. A new joiner must attest before going live. Provider users sometimes assume the provider's annual submission covers them. Confirm who submits your attestation, on what date, and whether your own entry is current in the application.

Mandatory controls not met

Most implementation for a provider user sits with the provider, but the controls on your own footprint, including your connection to the provider, remain yours. A gap in those controls leaves you non-compliant with mandatory controls even when the provider is fully compliant. Read the controls that apply to your architecture type and test your own side of the connection against each one.

No independent assessment

Every attestation must be supported by an independent assessment, performed internally by a second or third line team such as risk, compliance or internal audit, or externally. Providers often hold a Swift-specific audit of their own platform. That audit does not replace your assessment of your footprint. Ask your internal audit or an external assessor to scope your own environment and confirm the date on which it was completed.

Connection through a non-compliant provider

Swift reserves the right to report a user that connects through a non-compliant service provider, so your provider's status affects your standing. This is the trigger most likely to change without warning, because a provider can lose compliance after you have already attested. Check the provider's current status before go-live and at each attestation cycle, and make notice of status changes a term of your contract.

Swift-mandated external assessment not completed

Where Swift mandates an external assessment for a user, skipping or delaying it is a separate reporting trigger from a weak internal review. Provider users can miss this step when they expect the provider's assessment cycle to cover it. Confirm with Swift whether an external assessment applies to your user profile and schedule it independently of the provider's timetable.

Supervisor visibility in real time

Lack of compliance is visible to your supervisor in a dedicated real-time application, so a trigger does not stay inside Swift's systems. Supervisors can see the gap without waiting for your next attestation, which makes a lapse a visible governance issue. Treat each trigger as an event with a named owner, and review your provider's status and contract terms before assuming you are covered.

Which assessor type fits a provider user's own footprint

This table compares three ways to perform the independent assessment for the controls covering your own footprint: an internal second or third line review, an external provider that is not Swift CSP Assessor certified, and an external certified assessor. Read each row against your own architecture type and governance, because Swift leaves the choice of assessor to the organization and the attestation must still disclose how the assessment was done.

Option	When it fits	What the attestation must disclose	Independence and cost trade-off
Internal second or third line (risk, compliance or internal audit)	Your footprint is limited to your own connectivity to the provider, and an independent team outside the implementation work can test it	Assessor identity and function, that the team is independent of those who implemented the controls, and the assessment scope	Strongest cost control, but independence depends on reporting lines and skills; ask whether the team has the Swift-specific knowledge to test your footprint
External, not Swift CSP Assessor certified	Your footprint is more technical than a policy review, you lack in-house assessment skills, and you accept that certification is not required by Swift	Assessor name, that it is external, that it is not certified, and the scope and method used	Independence is stronger than internal review, with fees that depend on scope and the assessor's Swift knowledge; confirm its experience with the architecture type in your scope
External, Swift CSP Assessor certified	You want an assessor with a recognized Swift credential, or your counterparties and supervisors expect a certified assessor	Assessor name, that it is external, that it holds certification, and the scope and method used	Highest independence and the strongest credential, usually with higher fees; compare quotes on the same written scope
Mixed team (internal and external)	Internal teams can run controls testing while an external party reviews the technical items or the overall result	Each contributor's role, which parts were tested by whom, and who signed off the overall result	Can reduce external effort, but coordination and responsibility boundaries must be written down before work starts

What to ask a consultant before it helps with a provider user's footprint

A service bureau user still owns its own footprint under the CSP, so a consultant's first job is to scope that footprint correctly and stay out of the assessor's role. The checks below help procurement and the compliance lead confirm that the consultant works within those limits before any work starts.

Architecture decision tree scoping

Ask the consultant to walk through Swift's architecture decision tree and state which of the five architecture types (A1, A2, A3, A4 or B) it believes applies to your connection through the provider. The answer should limit the work to your own footprint, including your connectivity to the provider, and should not include the provider's own systems. A consultant that cannot explain the tree or that proposes controls across the provider's estate has misread the scope. Ask for the scoping rationale in writing.

Evidence preparation versus assessment

Ask how the consultant separates preparing evidence from performing the independent assessment. Preparing configuration records, access reviews and policy documents is implementation support. Forming the independent assessment conclusion is a separate role, and it must come from an internal second or third line team or an external assessor that you select. If the same people prepare the evidence and then test it, the independence that the attestation relies on is weakened. Request a written description of who does each task.

Provider expectations and audit coverage

Ask what the consultant expects from your connectivity provider and how it will verify the provider's Swift audit coverage. Swift states that most implementation for a connectivity provider applies to the provider and is covered by a specific Swift audit, so the consultant should confirm the provider's audit status rather than assume it. Ask for the evidence it will request, such as the provider's audit reference or confirmation that the provider is not a non-compliant service provider. Gaps here affect your own attestation.

No issuance of attestations or conclusions

Confirm in the contract that the consultant will not submit the KYC-SA attestation on your behalf and will not issue an assessment conclusion or report. Your organization makes the attestation in the KYC-SA application, and only an independent assessor performs the assessment. Ask the consultant to name the person in your organization who will submit and sign off, and to confirm it will not present itself as the assessor in any document shared with Swift or your counterparties.

Certified assessor recommendations

If your organization wants an assessor holding Swift's CSP Assessor Certification, ask whether the assessor the consultant recommends holds it. Certification is optional under Swift's framework, so its absence is not a failure, but the attestation must disclose the assessor's status accurately. Ask for the assessor's name, its certification status and how the consultant's relationship with that assessor is disclosed. Any referral fee or shared commercial interest should be declared before engagement.

Written scope before work starts

Ask for a written scope before any work begins. It should list the architecture type, the systems and connections in your footprint, the controls in scope, the deliverables, the timeline and the responsibilities of your staff and the provider. Fixed-scope agreements make it clear what is excluded, such as the provider's own implementation. Ask how changes to scope will be approved and recorded, because a scope that drifts into the provider's estate will change both cost and the attestation.

Questions service bureau users ask before they hire help

Does the service bureau's Swift audit remove my own CSP obligations?

No. Swift says that when you connect through a connectivity provider such as a service bureau, an L2BA or a Business Connect provider, most implementation applies to the provider and is covered by a specific Swift audit. You still implement the controls that apply to your own footprint, including your connectivity to the provider. Your attestation must be supported by an independent assessment of your environment, so the provider's audit does not stand in for your own evidence. Ask the provider exactly which controls its audit covers, then map the rest to your own systems, users and network paths.

How much effort will my team need to put into the CSP work?

Effort depends mainly on which architecture type applies to you, how many systems and administrators sit inside your footprint, and how much evidence of your current controls already exists. Swift says the controls in scope depend on how you connect, so start by working through its architecture decision tree. Your team will need time to read the general controls, confirm which ones apply, document your own configuration and collect records for the assessor. Ask any firm you consider to estimate effort from a written scope, and ask how much of that effort falls on your staff.

Can my organization complete the CSP work and assessment internally?

Often yes, provided the assessment is independent of the people who implemented the controls. Swift's Independent Assessment Framework allows an internal assessment by an independent department such as internal audit, or an external assessment by an assessment provider. Your internal team can prepare the controls and evidence, but the assessor must be able to test them without marking its own work. Swift's CSP Assessor Certification is optional. Confirm with your supervisors and any external assessor which team will sign off, and record that independence in your plan.

What do I need from my service bureau to prepare my attestation?

You need written information from the provider about what its Swift audit covers, which controls it implements on its side, and how its environment connects to yours. Ask for the scope of its most recent Swift audit, the controls it attests to, and any exceptions or remediation items that touch your connection. Confirm how you will receive evidence about the provider's controls when you need it for your own assessment. Put these requests into your contract or service schedule so the information is available each year, not only at the time of attestation.

How does the 31 December deadline shape my timeline?

Swift says users must attest no later than 31 December and re-attest at least annually between July and December. New joiners must attest before going live on the Swift network. Every attestation must be supported by an independent assessment, so the assessment has to finish before you submit in the KYC-SA application. Work backwards from 31 December: plan implementation, evidence collection, assessment and any remediation so that the assessor has time to review the results. If you are a new joiner, plan around the date you need to go live rather than the year-end deadline.

What happens if my service bureau is not compliant?

Swift reserves the right to report users that connect through a non-compliant service provider, and that report is visible to the user's supervisor in a dedicated real-time application. Your own attestation can still be affected by a provider problem because the connection is part of your footprint. Ask your provider for its current compliance status, check how it reports any gap, and agree in writing what happens if its attestation lapses. Build a contingency plan for changing provider so a compliance issue does not become an operational stop.

What drives the cost of help, and what should I ask a firm to quote?

Swift publishes no prices, and DeployOpen does not publish a price list either. Cost is driven by the architecture type and connectivity in scope, the number of systems and administrators inside your footprint, whether you use an internal or external assessor, the state of your existing evidence, and the remediation work a gap analysis uncovers. Ask any firm for a fixed-scope written proposal that lists the architecture type assumed, the systems covered, the deliverables, who performs each step and what is excluded. Also ask which parts recur each year, because the annual attestation and assessment repeat.

How DeployOpen prepares your footprint evidence for the assessor

Service bureau and connectivity provider users still own their own footprint under the Customer Security Programme. DeployOpen works on that footprint only: the systems, access paths and connectivity to the provider that the user controls, with the organization keeping ownership of every control and attestation decision.

How we scope

We confirm with you which architecture type applies, using Swift's architecture decision tree, before any work starts.
The written scope lists which systems, connections and access paths in your own footprint are covered, and which sit with your provider.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins, and a quote follows from that scope.

How we build

We implement the controls for your own footprint on self-hosted open-source platforms inside your own infrastructure.
We cover the connection between your environment and the provider, including the access controls and segregation you own on your side.
We run security testing against the in-scope components so gaps appear before your assessor reviews them.

How we hand over

We document each in-scope control with configuration records, access reviews and logs that your assessor can test.
We separate the evidence your team owns from the provider's audit material, so the attestation does not rely on assumptions.
Our deliverables are handed over to your team, which then decides how to present them to the independent assessor.

How we support

Ahead of each yearly attestation cycle, we can review changes to your footprint and update the evidence set.
Ongoing support, upgrades and continuous testing are available as a retainer for the in-scope platforms.
We do not issue attestations or assessment reports. Ask your independent assessor to confirm what evidence they need.