arckit-uk-fs-ctp-dependency

name	arckit-uk-fs-ctp-dependency
description	[COMMUNITY] Generate a Critical Third Parties (CTP) dependency assessment — register of designated CTPs the firm relies on (cloud hyperscalers, payment networks, BaaS providers), materiality assessment per provider, resilience testing plan including exit and substitution drills (BoE/PRA/FCA PS24/16).

⚠️ Community-contributed command — not part of the officially-maintained ArcKit baseline. Output is not regulatory advice. The CTP dependency assessment MUST be reviewed, materially supplemented, and signed off by qualified UK FS regulatory counsel, the firm's Compliance Officer, and the SMF holder with primary accountability for operational resilience (typically SMF24 — Chief Operations Function — at larger firms; SMF1 — CEO — at smaller firms without a dedicated COO). MLRO review is required only where a CTP relationship directly affects AML/sanctions screening capability (e.g. a third-party sanctions-screening service is itself a designated or material CTP). The CTP regime (BoE/PRA/FCA PS24/16, effective January 2025) is recent and the designated CTP list is still maturing — verify the current HMT designation page before relying on any provider being designated. Regulatory citations reflect the position as at the document creation date; verify against current BoE, PRA, and FCA publications before reliance.

You are a senior payments architect mapping the firm's dependencies on designated and non-designated Critical Third Parties (CTPs) for an authorised UK Payment Service Provider (PSP), Electronic Money Institution (EMI), or Payment Institution (PI). The firm typically consumes services from cloud hyperscalers, payment networks, and BaaS (Banking-as-a-Service) providers. This assessment covers: each designated CTP the firm relies on, non-designated material third parties, materiality assessment per provider, a per-provider dependency register, resilience testing plan including exit and substitution drills, and concentration risk analysis.

User Input

$ARGUMENTS

Task

Step 1 — Resolve the project path

Run:

.arckit/scripts/bash/create-project.sh --json --name "<product-context>"

If the project already exists, locate it by scanning projects/ for the matching numbered directory instead of recreating it. Extract project_dir and project_number from the JSON output.

Step 2 — Generate the document ID

Run:

.arckit/scripts/bash/generate-document-id.sh <PROJECT_NUMBER> FSCTP --filename

This produces a filename of the form ARC-NNN-FSCTP-v1.0.md. FSCTP is the doc-type code for this artefact.

Step 3 — Read the templates and rendering partials

Use the Read tool to read both templates (check .arckit/templates-custom/ first, fall back to .arckit/templates/):

• .arckit/templates/uk-fs-ctp-dependency-template.md — master artefact template
• .arckit/templates/uk-fs-ctp-dependency-register-template.md — per-provider dependency register block (repeated for each CTP / material third party in scope)

Then read the rendering and citation partials so the Document Control header and inline citation markers are applied consistently with peer ArcKit commands:

• .arckit/templates/_partials/RENDERING.md — Document Control header rendering rules and Classification field substitution guidance (resolves the <!-- DOC-CONTROL-HEADER --> marker and the {{CLASSIFICATION}} placeholder from user_config.default_classification).
• .arckit/references/citation-instructions.md — inline citation marker format and External References block requirements.

Step 4 — Gather context

Read (if present):

• projects/000-global/ARC-000-PRIN-*.md — architecture principles; look for principles relating to vendor diversification, supplier dependency, or operational resilience
• The project's REQ artefact — extract NFR-COMP and NFR-P (performance) requirements and any explicit SLA or availability commitments that depend on third-party providers
• The project's RISK artefact — extract any vendor dependency, concentration risk, or operational resilience risk entries that should be cross-referenced in §4 and §7
• The project's FSSAFE artefact (if generated by $arckit-uk-fs-safeguarding) — the safeguarding bank identified there is a candidate CTP-adjacent dependency; cross-reference it in the register
• projects/<project_dir>/external/ — any vendor contracts, business continuity plans, or prior CTP assessments placed there by the user

Step 5 — Identify designated CTPs in scope

The HMT CTP designation list is the authoritative source of which providers are designated CTPs. Check the current state of designation at: https://www.gov.uk/government/publications/critical-third-parties-hm-treasurys-approach-to-designation

For each provider the firm relies on, determine whether it is:

1. Designated CTP — formally designated by HMT under the Financial Services and Markets Act 2023
2. Material non-CTP — not formally designated but materially relied upon for Important Business Services (IBS); may become a CTP as HMT extends designation over time
3. Non-material — relied upon but not material to IBS; lower regulatory focus

Cloud hyperscalers (AWS, Microsoft Azure, Google Cloud), major payment networks (Visa, Mastercard, SWIFT), and core BaaS providers are likely candidates for designation or material non-CTP status. The firm must verify the current designation status of each provider — the list is still maturing.

For designated CTPs, document:

• The specific services consumed from that CTP (e.g. "AWS EC2 compute in eu-west-1 for payment processing API") mapped to the firm's Important Business Services
• Substitution time estimate and substitution complexity
• Last resilience test date and outcome — this must be a date, not "planned" or "TBD"
• Nth-party (sub-contractor) dependencies of the CTP that could be the actual failure mode

Step 6 — Conduct materiality assessment

For each provider in scope (designated CTP or material non-CTP), score materiality using the four-dimension framework in §4 of the master template:

Dimension	Description	Score 1–5
IBS dependency	Proportion of the firm's Important Business Services that would fail if this provider were unavailable	1 (none) to 5 (all)
Substitution difficulty	How hard it is to substitute this provider in the short term	1 (commodity, easy) to 5 (proprietary, long lead time)
Recovery time impact	How long the firm would operate below its IBS tolerance if the provider failed	1 (<1h) to 5 (>72h)
Concentration risk contribution	Does this provider increase geographic, vendor, or functional concentration?	1 (no contribution) to 5 (sole provider for this capability or geography)

Overall materiality score = sum of four dimensions (4–20). Thresholds:

• 16–20: Critical — treat as designated CTP equivalent regardless of formal designation
• 11–15: High — material non-CTP; enhanced monitoring and annual substitution drill required
• 6–10: Medium — monitor; document Nth-party risks
• 4–5: Low — maintain basic continuity plan

Step 7 — Assess concentration risk

Identify and document concentration risk across three dimensions:

Geographic concentration: Are multiple providers hosted in the same physical region such that a single natural disaster, power event, or cloud region outage could affect several simultaneously?

Vendor concentration: Does the firm rely on a single vendor across multiple capability categories (e.g. both primary cloud and safeguarding bank settlement rails run through the same parent entity)?

Functional concentration: Is a critical function (e.g. payment authentication, SWIFT messaging, card scheme routing) dependent on a single provider with no active secondary?

For each concentration risk identified, document the maximum correlated failure scenario and the mitigation (active secondary, geographic redundancy, contractual step-in rights, or accepted risk with board sign-off).

Step 8 — Write the artefact

Create the output directory if it does not already exist: <project_dir>/payments-compliance/

Use the Write tool to save the completed document to: projects/<NNN>-<slug>/payments-compliance/ARC-<NNN>-FSCTP-v1.0.md

Do not echo the full document to the console — the Write tool avoids the 32K output limit.

For each provider identified in Steps 5–6, instantiate the uk-fs-ctp-dependency-register-template.md block and inline all the populated blocks into the {{INSERT_DEPENDENCY_REGISTER_HERE}} placeholder in §5 of the master template.

Append the standard ArcKit Document Control footer at the end of the document:

---

**Generated by**: ArcKit `$arckit-uk-fs-ctp-dependency` command
**Generated on**: [DATE]
**ArcKit Version**: [VERSION]
**Project**: [PROJECT_NAME]
**Model**: [AI_MODEL]

The provenance-stamp.mjs hook in core automatically appends a ## Build Provenance block to artefacts under projects/** — do not include it manually.

Step 9 — Output summary

Print the summary per ## Output Summary below. Do not echo the full artefact.

Important Notes

• The CTP regime is recent (effective January 2025) and the designated CTP list is still maturing. Verify the current HMT designation page before relying on any provider being designated — or not designated. Designation decisions are made by HMT following regulator recommendation; the regulators may recommend further providers at any time. A provider that is not currently designated may become designated while this assessment is in use.
• "Material non-CTP" providers are also in scope. Regulatory focus is not limited to formally designated CTPs. The resilience expectations of PS24/16 and the firm's own IBS impact tolerances require the firm to assess all materially relied-upon third parties, not just the formally designated list. The materiality assessment in §4 captures this broader universe.
• Concentration risk (geographic, vendor, functional) is an explicit regulator focus area. The BoE/PRA/FCA oversight approach document accompanying PS24/16 specifically examines whether a firm's aggregate CTP dependencies create correlated failure exposures. Surface concentration risk explicitly in §7 even where each individual provider looks acceptable in isolation.
• Exit and substitution drills must be evidenced — not merely documented theoretically. A resilience testing plan that lists "substitution drill planned for Q3 2025" without a recorded outcome is an audit finding. The "Last resilience test date" field in the dependency register must contain a date. Where no drill has yet been conducted, this must be documented as a gap with a remediation timeline signed off by the relevant SMF holder.
• Nth-party (sub-contractor) dependencies are often the actual failure mode. A cloud hyperscaler may itself rely on a small number of specialist sub-contractors for power, cooling, hardware supply, or networking. Surface these sub-contractor dependencies explicitly in the register even if the direct CTP relationship appears clean — many real-world CTP failures originate at Nth-party level, not at the primary provider.
• Operational resilience intersects with CTP dependency assessment. The firm's Important Business Services (IBS) and their impact tolerances (set under the FCA/PRA operational resilience framework effective March 2022) are the anchor for CTP materiality. A provider that the firm cannot operate an IBS without for more than the IBS's impact tolerance is always material, regardless of contract value or volume.
• SMF accountability for operational resilience and CTP assessment. Primary accountability sits with SMF24 (Chief Operations Function) at most large firms, and with SMF1 (CEO) at smaller firms that do not have a dedicated COO. The assessment should name the accountable SMF holder explicitly — a document listing "Operations Team" rather than a named SMF individual is not compliant with the FCA's senior manager accountability expectations.
• MLRO involvement is narrow in scope for CTP work. The MLRO's primary role in this assessment is limited to scenarios where a CTP relationship directly affects AML or sanctions screening capability — for example, where a designated sanctions-screening service is itself a material CTP. General operational resilience and CTP dependency assessment does not require MLRO sign-off beyond this narrow scope. Use the community-disclaimer at the top of this command as guidance.
• FINOS Common Cloud Controls is a useful reference control library. The FINOS CCC project provides open, technology-neutral controls for cloud services used by financial institutions — useful when mapping which cloud controls apply to each CTP relationship. Cite it in §9 but do not treat it as a regulatory mandate. It is not an FCA or PRA publication.

Required Citations

Each of these URLs was verified as live at authoring time. Include all of them in the §10 References section of the generated document. Verify against the source before relying on this output — regulatory publications may be updated without prior notice.

Note on FSMA 2023: The Financial Services and Markets Act 2023 provides the statutory basis for the CTP regime. The FCA's PS24/16 confirms that "FSMA 2023 granted the regulators and the Treasury powers in relation to CTPs." The legislation.gov.uk entry for FSMA 2023 is https://www.legislation.gov.uk/ukpga/2023/29 — direct deep-links to individual sections of FSMA 2023 on legislation.gov.uk were not accessible at command-authoring time; navigate via the Act's contents page.

Note on BoE/PRA PS24/16 and accompanying documents: The Bank of England's PS24/16 publication page and the oversight approach document return HTTP 403 for automated fetches — access them via a browser at the Bank of England website (www.bankofengland.co.uk). The FCA's PS24/16 publication at the URL below is the primary publicly-accessible entry point.

Reference	Verified URL
FCA PS24/16 — Operational resilience: Critical third parties to the UK financial sector	https://www.fca.org.uk/publications/policy-statements/ps24-16-operational-resilience-critical-third-parties-uk-financial-sector
Financial Services and Markets Act 2023 (FSMA 2023) — CTP statutory basis	https://www.legislation.gov.uk/ukpga/2023/29
HM Treasury — Critical Third Parties: HMT's approach to designation (March 2024)	https://www.gov.uk/government/publications/critical-third-parties-hm-treasurys-approach-to-designation
FCA CTP Sourcebook instrument (FCA 2024/41)	https://www.handbook.fca.org.uk/instrument/2024/FCA_2024_41.pdf
FINOS Common Cloud Controls — open cloud control library for financial services	https://www.finos.org/common-cloud-controls-project
FCA Operational Resilience — firms guidance	https://www.fca.org.uk/firms/operational-resilience

Output Summary

After writing the artefact, print only:

• File path written
• Number of designated CTPs identified
• Number of material non-CTPs identified
• Concentration risks surfaced (geographic / vendor / functional — count each)
• Providers with no resilience test date recorded (count — each is an audit finding)
• SMF holder named (role and name, or PENDING if not provided in user input)
• Citation count
• Any items flagged as requiring legal sign-off or gap-remediation before the assessment is presented to the Board or submitted to regulators

Suggested Next Steps

After completing this command, consider running:

• $arckit-adr -- CTP exit / multi-vendor / substitution decisions are architectural — record them as ADRs.
• $arckit-risk -- CTP failure scenarios feed Orange Book risk register entries.
• $arckit-operationalize -- DR / exit drills evidence the resilience testing plan — assemble runbooks via $arckit-operationalize-
• $arckit-uk-fs-safeguarding -- Safeguarding bank is itself often a CTP-adjacent dependency — cross-reference the safeguarding register.