Reviewing counterparty SWIFT CSP attestations

An open remediation date on a mandatory control is a disclosed gap, not a clean result. Where a control is not yet met, the counterparty gives a remediation date in its KYC-SA attestation and updates the attestation once it is compliant. A reviewer should read that date as a commitment with a risk attached until the update arrives. Start by separating the open items by type. A mandatory control with a future date means the counterparty is not compliant today, so you need to know what the gap affects in your own flows, whether any compensating measure is in place, and whether the date falls before or after the period you need the relationship to be covered. An advisory control with a date carries less weight, but it still tells you how the counterparty plans its work.

Send the counterparty a short, specific set of questions rather than a general request for assurance. Ask which control ID is open, what the current state is, what the remediation plan involves, who owns it, and whether the date is still the one shown in the attestation. Ask whether the attestation has been updated since the date was set and whether the independent assessment covered the gap. Ask what interim safeguards apply to the Swift connection in the meantime, and when they expect to submit an updated attestation. Confirm the counterparty's current position directly with them or through the KYC-SA access you hold, because an attestation can be out of date and a date that has passed without an update is a question in itself.

Record the decision in your third-party file so the next reviewer can see what you knew and when. Note the control, the date shown, the date you checked, the counterparty's answer, the interim safeguards you accepted, and the trigger for re-review, such as an overdue date or a new attestation. Decide whether to accept the risk with a named owner and an expiry, restrict the relationship, or escalate. Keep the record with the attestation extract you reviewed, because the position you relied on may change once the counterparty submits its update.

Swift reserves the right to report Swift users that have no valid attestation, are not compliant with mandatory controls, did not perform an independent assessment, connect through a non-compliant service provider, or did not complete a Swift-mandated external assessment. For a counterparty, any of these conditions is a signal worth reading closely, because the lack of compliance is visible to that user's supervisor in a dedicated real-time application. Your counterparty may therefore already be aware of a follow-up question before you raise it, and the answer is the thing to examine.

Treat a missing, lapsed or incomplete attestation as a due diligence finding, not as a verdict. Record what you saw in KYC-SA when access was granted, note the date of the attestation, and check whether it covers the current CSCF version and the architecture type that matches the counterparty's connectivity. Then ask the counterparty, in writing, for its position: whether an attestation is in progress, what it has already filed, which mandatory controls remain open, and whether a Swift-mandated external assessment has been requested. Ask for the counterparty's own documentation rather than a summary alone.

Keep the outcome open while you gather facts. Your reason to ask is that the counterparty's compliance status affects your exposure to a message path you rely on, so the decision you need to make is whether to continue the relationship on current terms, add conditions, or escalate internally. Confirm with the counterparty whether it has been reported or whether any follow-up action is known to it, and record its answer. Do not assume a specific consequence from the existence of a report, and do not treat a silent counterparty as compliant.

The counterparty owns its controls, its assessment and its attestation. A Swift user implements the CSCF controls that apply to its architecture type, has them independently assessed, and submits the attestation in the KYC Security Attestation (KYC-SA) application. The reviewing organization does not run those controls or write that attestation, and it cannot change what the counterparty has declared. Your job is to decide whether the counterparty's declared position is acceptable for your third-party risk appetite, and to record that decision. Swift operates KYC-SA and sets the rules for who may view an attestation and when, so access to a counterparty's attestation depends on Swift's viewing policy, not on a request you make directly to the counterparty.

The independent assessment is the evidence behind the attestation, and only the assessor can issue it. The assessment may be performed internally by a second or third line function, or externally, and Swift's CSP Assessor Certification is optional. What you read in KYC-SA is the counterparty's own declaration, supported by the assessment it names. Confirm that the attestation names the department or company that performed the assessment, which Swift makes mandatory, and check whether it carries the certified assessor flag. Ask the counterparty for the assessment summary it holds, and treat a missing or thin summary as a finding in its own right.

A consultant can help you ask better questions, but cannot issue or certify a counterparty's attestation. An outside advisor can structure your review questions, compare answers against the architecture type a counterparty has declared, and help you set a monitoring cadence. That work is useful, but it produces your internal assessment of risk, not a Swift attestation or an assessor's opinion about the counterparty's controls. Be explicit in your records about which statements came from the counterparty, which came from its assessor, and which are your own conclusions. Decide before you start who signs off the third-party risk decision inside your organization, because that person, not the counterparty or the advisor, owns the outcome.