#TOTSCo HMAP Integration Guide — joining the CSF as a Hub MAP

Connected Services Framework (CSF) — Companion Document — Version 1.0 (Draft)

Maintained by the Telecom Technical Architecture Group (TAG). Companion to Part 2 §6 — TOTSCo Integration.

#Document Control

#1. Executive Summary

The Connected Services Framework (CSF) is the open-standard peer-to-peer transport for Switching for Business (SforB) and any future industry protocols the TAG adds to its baseline (for example, OTS Porting). TOTSCo participates in the CSF as a Hub MAP (HMAP) — a specialised MAP role that bridges TOTSCo's centralised hub model with the CSF's distributed peer-to-peer network. TOTSCo retains exclusive control of its own hub and its commercial relationships with subscribed CPs; the CSF integration is a transport bridge, not a replacement of TOTSCo's role.

Locked-down HMAP interface. Each CSF MAP exposes a dedicated HMAP interface exclusively for TOTSCo. This interface is not used by any other MAP or HMAP. The deliberate design intent is to give TOTSCo a locked-down, steady-state interface that does not change as the wider CSF evolves. CSF version increments, feature releases, and routing-group additions made by the TAG have zero impact on the TOTSCo HMAP interface — every exchange continues to work exactly as it does today. This is the single most important architectural commitment the CSF makes to TOTSCo, and it is the operating model assumed throughout this guide.

Message delivery at this boundary. The HMAP interface inherits TOTSCo's hub-side delivery policy — the OTA2 GPLB Switching for Business Message Delivery Principles bind TOTSCo's outbound delivery to its destination RCPs. The 1 s connection / 3 s response timeouts apply on both sides; TOTSCo applies its own linear / fixed-cadence retry schedules (5/10/15/20/25 s for Match Requests; 10/20/30/60 s + 60 s cadence for other messages); the CSF MAP receives async failure notifications from TOTSCo as a standard hub client. These hub schedules do not propagate into the wider CSF P2P transport because the interface is locked down. See Part 2 §4.7.4 The HMAP Boundary for the full bindings.

The integration is operationally small because most of the work TOTSCo would normally do for a new hub partner has already been done:

What remains for TOTSCo to do is bounded and well-defined. The TAG anticipates this is low-effort work because each item leverages infrastructure TOTSCo already operates — the integration is genuinely additive rather than transformative. TOTSCo's own engineering teams are best placed to estimate the specific effort against their internal resourcing model:

Why the work is low effort: Each item reuses an existing TOTSCo capability. Item 1 is a standard REST-over-OAuth client that TOTSCo's engineers have implemented many times. Item 2 is JSON merging into a backward-compatible structure (the CSF CP Registry is designed as a superset of the TOTSCo directory shape). Item 3 is a lookup table at the SforB boundary. Item 4 is configuration of an existing routing engine. Item 5 is endpoint provisioning that mirrors TOTSCo's existing per-partner dedicated-endpoint operating model. The items above introduce no new technology and no new operational paradigm — everything builds on infrastructure TOTSCo already runs every day for OTS and the existing SforB hub. Once commissioned, the recurring operational cost of HMAP participation is approximately the same as TOTSCo's existing hub-operator cost.

The remainder of this guide breaks the work into a five-phase plan, defines the test gates between phases, sets out the operational-commissioning checklist, and closes with the industry-level benefits the integration unlocks. TOTSCo's engineering and programme-management teams own the effort sizing against their own resourcing model — this guide describes the scope, not the schedule.

#2. Strategic Context — Why TOTSCo should integrate

#2.1 The collective industry benefit

UK business switching is being accelerated by the introduction of SforB. The industry's adoption rate depends on how easily Communications Providers (CPs) can participate. Today, MAPs and CPs can already exchange SforB traffic using the TOTSCo Hub. The Connected Services Framework (CSF), designed by the Telecom Technical Architecture Group (TAG), gives the industry two additional complementary routes into SforB on top of the existing TOTSCo Hub route:

• Managed via a CSF MAP: a CP subscribes to a CSF MAP and exchanges through that MAP's standard CSF outbound. The CSF supports multiple competing MAPs with commercial choice.
• Self-served as a MAP-of-1: a CP runs its own MAP infrastructure, exchanging messages directly with every other MAP on the CSF network.

These additional routes are intended to unlock rapid SforB expansion. Many smaller business CPs need to become compliant in a short window; offering them more than one route — without losing the existing TOTSCo Hub option — is the lever that makes industry-wide adoption practical.

By participating as an HMAP, TOTSCo becomes a first-class peer in this network — TOTSCo's subscribed SforB CPs can exchange messages with every CSF-side CP through a single TOTSCo connection, and CSF-side CPs can reach every TOTSCo-subscribed CP through their own MAP's standard CSF outbound. The industry as a whole sees an inflection: SforB can now scale not just by adding more TOTSCo subscribers, but by adding more MAPs — each of which carries one or more CPs.

Industry benefit: SforB adoption accelerates because the framework removes the single biggest objection any new entrant has — "do I have to commit to a long-term contract with a single hub operator before I can switch a single customer?" The answer becomes "no — you can onboard with a CSF MAP through a digital journey very quickly and exchange with the industry tomorrow, and renegotiate later if your needs change. A CP on the CSF can move to another MAP using the framework's built-in seamless migration process, become a MAP-of-1, or move to a MAP / operate as a CP on TOTSCo. This is about timing and choice, with the freedom to move as your business changes."

#2.2 TOTSCo's positioning

TOTSCo's existing role as the Ofcom-mandated single platform for OTS is unchanged by the CSF. OTS continues to operate as today — same hub, same RCPIDs, same processes, same commercial arrangements. This integration touches the SforB side only. It positions TOTSCo as a forward-looking industry participant who supports the open framework while continuing to deliver the regulated OTS service.

Four direct benefits to TOTSCo:

#2.3 OTS is unaffected

This guide describes the integration of TOTSCo's SforB (GPLB) hub with the CSF. TOTSCo carries both OTS and GPLB (SforB) traffic today; the CSF integration only touches the SforB side. OTS is out of scope:

• OTS is mandated by Ofcom to use TOTSCo as the single industry platform. The CSF makes no claim on OTS traffic.
• A CP that uses TOTSCo for OTS only is unaffected by the CSF — their TOTSCo subscription, RCPID allocation, and message flows continue as today.
• A CP that uses TOTSCo for both OTS and SforB can choose to move only their SforB traffic to a CSF MAP, MAP-of-1, or any future arrangement — OTS continues on TOTSCo. See Part 1 §7.4.1 for the formal scope statement.

TOTSCo's directory carries both networks side-by-side today. The TOTSCo pre-production Directory v2 already combines RCPID, brand, and processSupport[].status entries for both OTS and GPLB in a single response. MAPs that want a single-process view filter by an identity query parameter:

https://preprod.otshub.totsco.co.uk/directory/v2/entry?listType=RCPID&identity=all
https://preprod.otshub.totsco.co.uk/directory/v2/entry?listType=RCPID&identity=ots
https://preprod.otshub.totsco.co.uk/directory/v2/entry?listType=RCPID&identity=gplb

We assume the same filter pattern will apply in production. The CSF's own Master Registry follows the same shape (process-tagged entries co-existing in one list), so TOTSCo's existing filtering logic carries forward unchanged.

Throughout this guide, every reference to "messages", "registries", and "RCPIDs" refers to the SforB (GPLB) transport only unless explicitly stated otherwise.

#3. What stays the same

Before describing the changes, this section enumerates what TOTSCo does not need to change. The list is deliberately long to make clear how much of the integration is already done.

Reassurance summary: The integration is additive. Nothing in the existing TOTSCo Hub setup is being changed or removed.

#3.1 Side-by-side directory format — TOTSCo vs CSF

The CSF CP Registry was deliberately designed to mirror the TOTSCo directory structure so TOTSCo can consume it with its existing parser. The CSF adds a small number of optional fields (signing[], expanded resource[], contact[], outage[]); TOTSCo may use them or ignore them — either choice is supported by the JSON contract and neither breaks existing code.

TOTSCo format (today):

"list": [
    {
        "listType": "RCPID",
        "identity": [
            {
                "id": "RTLL",
                "name": "NowYoYo",
                "processSupport": [
                    {
                        "process": "OTS",
                        "status": "ACTIVE"
                    }
                ],
                "resource": [
                    {
                        "name": "salesAssistURL",
                        "type": "URL",
                        "value": "https://nowyoyo.com/ots/sales-assistance/"
                    },
                    {
                        "name": "customerAssistURL",
                        "type": "URL",
                        "value": "https://nowyoyo.com/ots/customer-assistance/"
                    }
                ]
            }
        ]
    }
]

CSF format (superset — extra fields are additive, never breaking):

"list": [
    {
        "identity": [
            {
                "id": "c42569a5-d0ed-46f7-b9df-4ea0ba6a29c8",
                "name": "Red Company ISP",
                "processSupport": [
                    {
                        "process": "GPLB",
                        "status": "ACTIVE"
                    }
                ],
                "resource": [
                    {
                        "name": "customerAssistURL",
                        "type": "URL",
                        "value": "https://gplb.red-company.com/customerAssistURL.html"
                    }
                ],
                "signing": [
                    {
                        "domain": "gplb-test.nowyoyo.net",
                        "routingID": [
                            "businessSwitch.*"
                        ]
                    }
                ]
            }
        ]
    }
]

What this means for TOTSCo's parser: identical top-level structure (list[]/identity[]/processSupport[]/resource[]). The id value is wider for CSF (UUIDv4 instead of 4-character) but both are valid string values under the JAM specification. The signing[] block is CSF-only; TOTSCo can ignore it without code changes. CSF MAPs publish the same processSupport[].process values (OTS, GPLB) that TOTSCo already uses, so process-based filtering is identical on both sides.

#4. What needs to change

Five concrete deliverables. Each is small. Items 1–4 are mandatory; Item 5 (per-MAP dedicated endpoints) follows the same per-partner operating pattern TOTSCo already runs for every OTS and SforB partner.

Architectural commitment. The CSF MAP-side HMAP interface presented to TOTSCo is locked down. Once a MAP and TOTSCo have agreed the interface contract, no CSF spec increment, feature release, or routing-group addition modifies it. TOTSCo's build below is a one-time integration, not an evergreen one. See §1 for the architectural commitment in full.

#4.1 Item 1 — Directory API client

What: A small Directory API client that, on a polling schedule, retrieves each CSF MAP's CP Registry as a JSON document over HTTPS using OAuth 2.0.

Why: The CSF is decentralised; there is no central registry. Every CSF MAP publishes its own CP Registry containing the metadata for its own CPs and itself (contacts, status, signing keys, routing groups, sponsorship, outage). TOTSCo collects these into a private converged view (§6.4 Directory Collection).

How:

• TOTSCo provisions OAuth 2.0 client credentials with each CSF MAP (the same way MAPs already provision credentials with TOTSCo).
• TOTSCo polls each MAP's Directory API endpoint (typical URL form: https://api.{mapdomain}/directory) using GET over HTTPS with a bearer token.
• Recommended polling frequency: 5 minutes (the CSF supports anything from 60 seconds upward — see Part 2 §5). Hourly polling is acceptable for steady-state operations.
• Response is application/json; TOTSCo parses and stores.

Technical note: This is a standard REST-over-OAuth pattern TOTSCo's engineers have implemented many times. No new libraries are required; any HTTP client + JSON parser will do. The initial CSF MAP set is anticipated to be fewer than 10 MAPs in the first 12 months, so the polling load is trivial.

#4.2 Item 2 — Master Registry convergence

What: Merge the collected CSF CP Registries into TOTSCo's existing Master Registry, or maintain them as a parallel store keyed by RCPID.

Why: TOTSCo needs to know which CSF MAP serves each CSF-side CP so it can route SforB messages correctly. It also benefits from the contact, outage, and service-status data each CSF MAP publishes about itself (Section 2.2 benefits).

How:

• Each CP Registry has two main sections: map (the publishing MAP's metadata) and list (the CPs that MAP serves).
• For each CP, TOTSCo records: the CP's UUIDv4 RCPID, brand name, supported processes (processSupport[] — typically GPLB / SforB), the publishing MAP's name, the MAP's CSF letterbox URL, and the contact entries.
• For each MAP, TOTSCo records: name, status, contact entries, outage array, service-status URIs, routing groups, and connectivity endpoints.
• The CP Registry format is deliberately backward-compatible with TOTSCo's existing OTS directory structure — convergence is JSON-level merging, not transformation.

Best practice: TOTSCo may choose to maintain the CSF MAPs and CPs as a logically separate "CSF zone" inside the Master Registry so that OTS operations remain unaffected by any CSF directory updates. The CP Registry schema supports this naturally — each CP's RCPID format (4-char OTS vs UUIDv4 CSF) is unambiguous.

#4.3 Item 3 — RCPID translation

What: At the SforB-traffic boundary, translate RCPIDs between the CSF UUIDv4 format and the TOTSCo 4-character RCPID format.

Why: CSF MAPs send messages using UUIDv4 RCPIDs (per Part 1 §8 RCPID Management). TOTSCo's hub internally uses 4-character RCPIDs (e.g. RTLL, BBBX) for its own clients — the same 4-character format is used by TOTSCo for both OTS and GPLB (SforB) today, so this translation is no different from any OTS-style lookup TOTSCo already performs. Both formats are valid source.identity / destination.identity values under the JAM Specification (which allows strings up to 256 characters), so the translation is purely a Hub-side lookup, not an envelope rewrite.

How (§6.5 RCPID Format Handling):

• For a CSF→TOTSCo flow: the inbound JAM envelope carries a UUIDv4 in destination.identity. TOTSCo looks up the UUIDv4 in its Master Registry, identifies that this is a TOTSCo-served CP, and routes the message to that CP using its existing internal mechanism. The 4-character RCPID is the TOTSCo-internal handle; the CSF MAP never sees it.
• For a TOTSCo→CSF flow: TOTSCo's own CP sends a SforB message with a 4-character destination.identity (the TOTSCo-internal RCPID of the destination CSF-side CP). TOTSCo translates this to the UUIDv4 RCPID before forwarding to the CSF MAP. The CSF MAP receives a standards-compliant UUIDv4 in its inbound message.
• The translation table is maintained by TOTSCo internally as part of Master Registry convergence (each CSF-side CP's UUIDv4 is paired with whatever 4-character handle TOTSCo allocates to that CP for its existing addressing).

Technical note: The translation is one-way visible — TOTSCo's CPs see only the 4-character format they are already familiar with; CSF MAPs see only the UUIDv4 format. Each side speaks its own dialect; the Hub bridges. This pattern is identical to how email gateways translate between internal and external address representations.

#4.4 Item 4 — Routing rules

What: Configure TOTSCo's existing message-routing layer so that outbound SforB messages with a CSF-side destination are routed to the correct CSF MAP's letterbox URL.

Why: TOTSCo's existing hub knows how to route messages between its own subscribed MAPs. The CSF integration adds new routing destinations: CSF MAPs that are not commercially subscribed to TOTSCo but are reachable through the standard CSF Directory API.

How:

• For each CSF MAP in the converged Master Registry, TOTSCo records the CSF letterbox URL (map/connectivity/services[].url for the service with messaging type and GPLBMessages routing group).
• When TOTSCo receives a SforB message destined for a CSF-side CP, the existing routing layer looks up the destination CP's MAP and posts the JAM envelope to that MAP's letterbox URL.
• The post uses OAuth 2.0 (with the credentials provisioned in Item 1) and TLS 1.3. The response is HTTP 202.

This item is largely configuration of TOTSCo's existing routing engine; no new routing technology is introduced.

#4.5 Item 5 — Dedicated per-MAP CSF letterbox endpoints

What: Expose dedicated TOTSCo letterbox URLs for CSF MAPs to deliver SforB messages into the TOTSCo Hub — one dedicated endpoint per CSF MAP, mirroring the per-partner dedicated-endpoint pattern TOTSCo already operates for OTS and SforB partners today.

Why (§6.3 Registering CSF Endpoints): TOTSCo's standard operating pattern is to provision a dedicated endpoint for each CP and MAP on its network. When TOTSCo acts as an HMAP on the CSF, the same pattern applies: TOTSCo creates a dedicated endpoint per CSF MAP through which it routes messages to that MAP's CPs. This:

• Matches the locked-down HMAP interface commitment in §1 — each MAP has its own contract with TOTSCo and is unaffected by changes to any other MAP's interface.
• Lets TOTSCo iterate or retire one MAP's CSF relationship without touching the others.
• Keeps the OTS / direct-SforB inbound endpoints fully separated from the CSF inbound endpoints.

How:

• TOTSCo provisions a per-MAP HTTPS endpoint (e.g. https://csf.totsco.org.uk/letterbox/<map-handle>) backed by the same hub infrastructure.
• TOTSCo publishes each per-MAP URL to the corresponding CSF MAP via the standard onboarding handover documented in §6.3.
• Each endpoint accepts the same JAM envelope, the same OAuth 2.0, the same TLS 1.3 — the only difference is the URL path.

This item is configuration only — DNS provisioning, TLS certificate issuance, and endpoint routing — no new code.

Why the per-MAP pattern matters: HMAP endpoints are deliberately static. Each CSF MAP exposes a dedicated HMAP interface exclusively for TOTSCo (locked down, see §1), and TOTSCo reciprocates with a dedicated CSF inbound endpoint exclusively for that MAP. The two endpoints form a bilateral, contract-frozen pair. Changes elsewhere in the CSF — at other MAPs, in newly added routing groups, in envelope conventions — never reach the pair.

#5. Step-by-step integration plan — 5 phases

The five phases below align with TOTSCo's typical large-programme delivery rhythm. Each phase has an entry criterion, an exit gate, and a clear set of deliverables. TOTSCo's programme-management team owns the scheduling — this guide describes the scope and the gates between phases, not the calendar duration.

#Phase 1 — Discovery and Planning

Activities

• Read Part 1 of the CSF and Part 2 §5 Directory API and Part 2 §6 TOTSCo Integration. Read the TOTSCo Hub API v2.0 specification alongside, noting the JAM-envelope and OAuth-flow equivalence.
• Inventory the CSF MAPs in scope for the first wave (the framework anticipates < 10 MAPs in the first 12 months).
• Decide whether to maintain CSF MAPs / CPs in TOTSCo's existing Master Registry or in a parallel store (see §4.2 Best Practice).
• Confirm the per-MAP CSF letterbox URLs (Item 5) and obtain the necessary DNS / certificate provisioning lead time.
• Identify the operational contacts who will own the CSF integration once live (escalation, on-call, monitoring).

Deliverables

• Integration design document (one-pager: the five items above, the chosen registry model, named operational owners)
• TOTSCo internal RACI for the build
• Cost-and-effort estimate confirmed against this guide's §1 figures

#Phase 2 — Build

Activities

• Build Item 1 (Directory API client).
• Build Item 2 (Master Registry convergence).
• Build Item 3 (RCPID translation).
• Build Item 4 (Routing rules).
• Configure Item 5 (per-MAP dedicated CSF letterbox URLs).
• Provision OAuth 2.0 client credentials with each in-scope CSF MAP.

Deliverables

• Items 1–5 in TOTSCo's pre-production environment
• Pre-production OAuth credentials with each in-scope CSF MAP
• Component test results
• Cut-over plan from pre-production to production

#Phase 3 — Test

Activities

• Run the test patterns in §7 of this guide against each in-scope CSF MAP:
  • Directory pull (Item 1)
  • Master Registry merge (Item 2)
  • RCPID translation round-trip (Item 3)
  • Outbound message routing (Item 4)
  • Inbound message receipt at the dedicated CSF letterbox URL (Item 5)
• Run the bidirectional worked example below to confirm end-to-end traffic in both directions.
• Confirm that all messages are marked with auditData.test=true while in test mode (per §5 Test Traffic Flagging).

#Worked example — bidirectional SforB exchange via TOTSCo HMAP

This would normally be looked up in the MAP Registry; here it is shown inline so the test team can run the exchange end-to-end. The intent is to confirm that a TOTSCo-side CP (already established on the TOTSCo Hub) can exchange messages with a CSF-side CP, with TOTSCo acting as the HMAP between them. TOTSCo may instead use its own Virtual CP (VCP) if it prefers.

TOTSCo Hub Transport (TOTSCo-side CP, already live on the Hub today)

This CP is managed by the NowYoYo MAP, which has an established connection with TOTSCo and can already send and receive messages within the TOTSCo Hub among BBBX, BBBY, and other locally-served brands.

CSF Peer Transport (CSF-side CP, behind a CSF MAP)

Credential setup: TOTSCo will need credentials established in the normal way with the CSF MAP providing the Red Company endpoint — TLS 1.3 with OAuth 2.0 plus IP allowlisting.

Test 1 — TOTSCo → CSF: BBBX sends a businessSwitchMatchRequest to the TOTSCo Hub in the normal way, but with destination.identity set to the CSF-side CP. TOTSCo routes the message via the dedicated CSF letterbox endpoint to the receiving CSF MAP, which delivers it to Red Company.

Test 2 — CSF → TOTSCo: Red Company sends a businessSwitchMatchRequest from the CSF MAP via the dedicated HMAP interface to TOTSCo. TOTSCo then routes the message onto BBBX via the NowYoYo MAP using the connection already established for OTS/SforB.

The sequence diagram below shows both directions of the exchange:

Deliverables

• Signed-off test report
• Confirmation from each in-scope CSF MAP that bilateral handshake is complete
• Any observed defects logged and triaged

#Phase 4 — Operational Commissioning

Activities

• (Optional, value-add) Wire the CSF MAPs' map/outage[] arrays into TOTSCo's existing operational dashboard so the operations team has a real-time view of CSF MAP service status. The map/outage[] array is optional in the CSF CP Registry — when populated by a CSF MAP it gives TOTSCo a free real-time outage feed that can materially reduce delivery-failure investigation time.
• (Optional, value-add) Wire the CSF MAPs' map/serviceStatusServiceURI into TOTSCo's existing monitoring stack. Also optional in the CSF schema; when present it provides a programmatic health probe per MAP.
• Set up alerting on inbound message receipt failures, OAuth token expiries, and Directory API pull failures.
• Document the production cutover plan (which CSF MAPs go live in which order; how to roll back if a defect is found in production).
• (Recommended, not required) Configure the regression suite to run quarterly against the live CSF MAPs (per Onboarding & Testing Process §11). Because the HMAP interface is locked down (§1), this is a periodic sanity check rather than a change-detection regimen.

Deliverables

• Operations runbook (alert thresholds, escalation, rollback procedure)
• Operational dashboard updated to include CSF MAP status
• Quarterly regression suite scheduled
• Go-live readiness sign-off

#Phase 5 — Production Operations (Ongoing)

Activities (steady state)

• Operate the CSF inbound and outbound flows alongside the existing TOTSCo OTS and SforB flows.
• (Optional) Run the quarterly regression suite as a periodic sanity check.
• No action required for CSF version increments announced by the TAG. The locked-down per-MAP HMAP interface (§1) is intentionally insulated from CSF spec changes — envelope changes, new routing groups, and feature releases do not propagate through the dedicated TOTSCo endpoints. If a CSF MAP voluntarily chooses to expose a new interface in addition to the locked-down HMAP one, that is a bilateral conversation between that MAP and TOTSCo and only proceeds under TOTSCo's own change-control process.
• Report any incidents to the TAG via the standard TAG incident-coordination route.

Deliverables

• Operational HMAP service on the CSF
• Continued operation of the OTS hub and the SforB hub for TOTSCo's directly-subscribed CPs

#6. Architecture sketch

The diagram below shows the end-state architecture. Note that the OTS Hub (top) is unaffected; the CSF integration adds the new flows shown at the bottom.

Reading the diagram:

• The OTS Hub (top box) is untouched.
• The SforB Hub gains new internal routes to a set of per-MAP dedicated CSF letterbox URLs (right-hand side of the SforB Hub box). Each CSF MAP has its own URL — the same per-partner pattern TOTSCo already uses for OTS and direct-SforB partners.
• The CSF (bottom) is the existing distributed peer-to-peer network of CSF MAPs and MAP-of-1 CPs, each publishing their own CP Registry.
• The dotted arrow on the bottom-right shows the periodic registry pull — the only outbound TOTSCo→CSF flow that does not carry JAM envelopes.
• The two-way arrows between the CSF letterbox URL and each CSF MAP are the actual SforB message exchanges, using the JAM envelope, OAuth 2.0, and TLS 1.3 already familiar to TOTSCo's infrastructure.

#7. Testing — patterns and gates

This section gives the offshore team a copy-and-run-style test plan. The patterns assume the team has access to TOTSCo's pre-production environment and OAuth credentials with at least two in-scope CSF MAPs. The CSF transport-level tests in Onboarding & Testing Process §8 are the canonical reference; the subset below is what an HMAP integration needs.

#7.1 Test T-01 — Directory pull (Item 1)

#7.2 Test T-02 — Master Registry merge (Item 2)

#7.3 Test T-03 — RCPID translation round-trip (Item 3)

#7.4 Test T-04 — Outbound message routing (Item 4)

#7.5 Test T-05 — Inbound message receipt (Item 5)

#7.6 Test T-06 — End-to-end SforB exchange (composite)

#7.7 Test gates for production cutover

A CSF MAP relationship goes to production only after T-01 through T-06 pass. The relationship is announced to the TAG by both TOTSCo and the CSF MAP for inclusion in the TAG's published bilateral-connectivity record.

#8. Operational commissioning

#8.1 Monitoring

TOTSCo's operations team should wire the following CSF-supplied data into the existing operational stack. The three CSF MAP-published fields below (map/outage[], map/serviceStatusServiceURI, map/contact[]) are optional in the CSF CP Registry schema, but each is a useful value-add for TOTSCo when a MAP populates it.

#8.2 Availability target

The CSF mandates 99.95% availability ("three nines and a five") — deliberately aligned with the TOTSCo Availability Target so industry SLAs remain consistent. TOTSCo's existing infrastructure already operates at this level for OTS; the CSF letterbox endpoint should inherit the same operational treatment.

#8.3 Incident response coordination

When a CSF MAP raises an incident affecting traffic to / from TOTSCo:

• The CSF MAP records the incident in its map/outage[] array (priority P1 / P2 / P3, start time, affected services, description). TOTSCo sees this on the next Directory pull.
• TOTSCo's operations team uses the CSF MAP's map/contact[] escalation entries to coordinate directly.
• If the incident is security-related, the CSF mandates 24-hour vulnerability notification and 72-hour breach notification (per Part 1 §10.6.5). TOTSCo's operations team follows its existing incident-response process and notifies the TAG via the standard route.

#8.4 Regression suite

Because the HMAP interface is locked down (§1), TOTSCo is not obliged to run the CSF regression suite on a fixed cadence. Two triggers are worth supporting:

• Every internal TOTSCo release that touches the CSF letterbox, Master Registry, or routing layer — this is a normal change-control regression and protects against TOTSCo-side drift.
• (Recommended, optional) Quarterly as a baseline conformance check. The HMAP interface itself is static, so this is a sanity check rather than a change-detection regimen. TOTSCo may choose any schedule that fits its release cycle, including skipping the check entirely.

The regression subset to run is documented in Onboarding & Testing Process §11.

If a failure is observed, it is reported to the TAG within one working day. The TAG may, in consultation with the steering group, coordinate with TOTSCo to investigate.

#8.5 Diagnostics

For incident diagnosis, TOTSCo has the following CSF-supplied diagnostic data available:

• The auditData[] array in the JAM envelope (correlation IDs, session metadata, test flag)
• The optional X-CSF-ROUTE HTTP header (records the route a message has taken through the CSF, useful for bridged messages)
• The structured 9xxx (industry) error codes in synchronous responses
• Per-MAP service-status URLs and operational contact details in the registry
• TOTSCo's own existing audit-log infrastructure carries forward unchanged

#9. Why this is low-effort work

TOTSCo's engineering and programme-management teams own the effort estimate against TOTSCo's own resourcing model. This guide does not prescribe numbers; it describes the scope and the reasons that scope is small. Five observations support the low-effort framing:

Ongoing operational cost: approximately the same as TOTSCo's existing hub-operator cost. The CSF integration adds a small additional polling load (< 10 CSF MAPs anticipated in the first 12 months) and a small additional inbound traffic stream on the per-MAP dedicated CSF letterbox URLs.

No recurring CSF licensing fee. The CSF framework is published as an open standard with no per-message, per-MAP, or per-CP charges. TOTSCo's commercial offering to its own subscribed CPs is unchanged.

The TAG is available to support TOTSCo's internal effort estimation if useful — including walkthroughs of the test patterns in §7, reference-implementation pointers, or clarifications of the CP Registry schema in §5 of Part 2 §5 Directory API. Outreach is via the standard TAG steering-group contact route.

#10. Risks and mitigations

#11. Collective benefits for the industry

This integration is a meaningful inflection point for UK business switching. The benefits flow in three directions.

#11.1 For TOTSCo

(Repeated from §2.2 for the management-summary reader.)

#11.2 For TOTSCo's own subscribed CPs

#11.3 For the wider industry — SforB acceleration through MAPs

The CSF's MAP model is the scaling mechanism for SforB adoption. Before the CSF, every SforB participant had to negotiate a relationship with the centralised hub. After the CSF, the industry has three concurrent routes:

1. Continued TOTSCo subscription (the existing managed route)
2. Subscription to a CSF MAP (a different managed route, with commercial choice)
3. MAP-of-1 self-service (CPs operating their own MAP)

Each route accelerates adoption for a different segment of the industry:

• Tier-1 CPs already on TOTSCo continue without change. Adoption is preserved.
• Mid-tier CPs gain a commercial-choice route (multiple CSF MAPs competing for their business). Adoption widens.
• Technically-capable CPs (or specialist SforB operators) can self-serve via MAP-of-1. Adoption deepens.

TOTSCo's HMAP role makes all three routes interoperable. Without TOTSCo's HMAP participation, the framework would fragment into "TOTSCo CPs" and "CSF CPs". With TOTSCo's HMAP participation, the framework is a single industry network with multiple commercial models — exactly the outcome the SforB process aims for.

The industry-level argument: SforB cannot accelerate without simultaneous expansion of all three routes. TOTSCo's HMAP integration is the single most significant unlock for that expansion. The integration is low-cost for TOTSCo (this guide is the evidence) and high-value for the industry. The framework is designed to make TOTSCo's continuing role easier, not harder.

#12. Frequently Asked Questions — pointers

The most common questions from TOTSCo and from CPs are answered in two existing FAQ documents that this guide does not duplicate:

• FAQ — TOTSCo Integration — answers TOTSCo's own questions about impact, API modifications, RCPID handling, service levels, diagnostics. Read alongside this guide.
• FAQ — GPLB Steering Group — answers the GPLB Steering Group's questions about RCPID assignment, multi-MAP CPs, directory mechanics, due diligence, test mode, and high-volume handling. Useful background for the integration design.

Both FAQs are companion reading. Where they overlap with this guide, the guide takes precedence as the more current and operationally-detailed view.

#13. References

#CSF documents (this repository)

• Part 1 §6 Security Overview — OAuth 2.0 and DNS records per CP
• Part 1 §8 RCPID Management — UUIDv4 allocation, OTS/GPLB compatibility
• Part 1 §10 Governance — TAG, dispute resolution, incident response coordination
• Part 2 §5 Directory API (CP Registry) — the JSON schema TOTSCo will consume (designed as a superset of the TOTSCo directory shape)
• Part 2 §6 TOTSCo Integration — the framework-side view this guide is the TOTSCo-side companion to
• Part 2 §8 Commercial Scenarios — CP Emergency Migration; covers the case where a CSF MAP withdraws mid-integration
• Part 2 §10 FAQ — GPLB Steering Group
• Part 2 §11 FAQ — TOTSCo Integration
• Onboarding & Testing Process — full TAG baseline test suite, status model, regression suite
• Definitions — terminology including HMAP, MAP-of-1, KYC, bit pipe

#External documents

• TOTSCo Hub API Specification v2.0 (April 2026) — TOTSCo's canonical transport specification. The integration described here uses the same JAM envelope, OAuth 2.0, and TLS 1.3 transport that v2.0 specifies; the CSF integration adds inbound and outbound JAM exchanges with new MAPs on the standard TOTSCo letterbox pattern.
• JSON Asynchronous Messaging Specification (JAM) — published on the OTA2 website; the message envelope shared by OTS, SforB, and CSF
• RFC 6749 — OAuth 2.0 framework
• RFC 8446 — TLS 1.3

#14. Document Control