#FAQ — GPLB Steering Group

Connected Services Framework (CSF) — Standalone Companion Document — Version 2.0

These questions were originally proposed by the GPLB Steering Group and discussed on 8 April 2025. The FAQ has since been updated to reflect the consolidations and ratifications in the framework — most notably the CP Emergency Migration (§8.2), MAP-of-1 Onboarding incl. TOTSCo → CSF migration (§7.4), the Sponsorship Object rotation rules (§5.4.2), the OTS-scope clarification, the Tier-3 dispute-resolution model, the bit-pipe / SOR definitions, and the anti-competitive safeguards (§10.6.7).

This document lives in the standalone section so it can grow over time without being tied to the Part 2 numbering. Cross-references below use paths relative to the standalone folder.

#Q1 — How will RCPIDs be assigned? Does the RCPID follow the CP or the MAP?

The RCPID follows the CP — for life.

RCPIDs are self-allocated by MAPs using UUIDv4 format after due diligence and onboarding. No MAP in the TAG group uses the allocated RCPID directly with their CPs — all use the branded name in search and drop-down lists. The RCPID is machine-readable only.

The RCPID stays with the CP brand permanently, enabling movement between MAPs, consolidation, mergers, and even a CP becoming a MAP of 1. All orders associated with the RCPID remain tied to it and can be migrated between MAPs — even in-flight — without impact on end consumers.

OTS compatibility: MAPs (including TOTSCo) can continue to use the 4-character OTS / GPLB Rxxx format internally, mapping to UUIDv4 for CSF SforB message exchange.

Migration-specific rules. For a CP migrating SforB traffic from TOTSCo to a CSF MAP-of-1, a new UUIDv4 RCPID is allocated and the legacy TOTSCo Rxxx is retired for SforB — see §7.4.8 RCPID Allocation Rule. For an emergency migration triggered by a MAP failure, the same brand keeps its CSF UUIDv4 across the transition — see §8.2.8 Fee Guidance and the RCPID-continuity rules attached to it. OTS RCPIDs are out of scope — OTS is Ofcom-mandated to use TOTSCo, so a CP's OTS Rxxx continues at TOTSCo unchanged regardless of any SforB migration.

See RCPID Management for the full normative reference.

#Q2 — If a CP moves from a MAP to TOTSCo, can they take their RCPID?

Yes — and the reverse direction is now fully documented.

TOTSCo is a MAP in the context of SforB, so any RCPID created by a MAP can be freely transitioned between MAPs (including to TOTSCo or to a CSF MAP-of-1). The TAG has ensured that CPs are not locked into any MAP in either direction.

The CP → TOTSCo direction has always been straightforward. The CP → CSF-MAP-of-1 direction (the strategically important escape path for a CP currently on TOTSCo for SforB) is now spelled out end-to-end in §7.4 MAP-of-1 Onboarding (incl. TOTSCo → CSF Migration). Headlines:

• Capability checklist before migration begins (§7.4.4).
• Sponsor MAP fast-track for single-cp engagements (§7.4.5).
• Big-bang cutover — the industry directory carries a brand once per process (§7.4.7).
• In-flight order handling — drain on TOTSCo or reconcile from the CP's CRM (CP's choice).
• New UUIDv4 RCPID allocated for SforB; legacy TOTSCo SforB Rxxx retired (§7.4.8).
• Phase 4 relaxations for MAP-of-1: 72-hour soak and ≥50% bilateral coverage waived because the CP carries the operational risk directly (§7.4.9).

Note — OTS is out of scope. OTS is Ofcom-mandated to TOTSCo, so OTS RCPIDs do not migrate to CSF. Only SforB RCPIDs do.

#Q3 — Can a retail CP use multiple MAPs?

Yes. A CP can operate different brands across different MAPs, provided each RCPID (brand) is formally set up with its respective MAP. This allows CPs to trial going independent, use specialist MAPs for specific use cases, or segregate trading lines for governance reasons.

This is enabled by the CSF's bit-pipe principle (see Definitions §2.3) — the CSF is the transport, not the business state. A CP brand with a CSF UUIDv4 RCPID on one MAP and a separate brand UUIDv4 on a different MAP is operationally normal. Different brands on different MAPs do not interfere with each other; the industry directory carries each brand once per process.

See also §7.4.2 Strategic context — the CP remains in control.

#Q4 — How is the directory created, shared, and how often is it updated?

Each MAP hosts its own CP Registry containing its CPs and metadata. Other MAPs collect these CP Registries (recommended maximum frequency: every 60 seconds) and converge them into a private Master Registry containing all CPs across the network.

From the Master Registry, each MAP derives a Directory — a filtered view containing just the brand names and RCPIDs — which is shared with its own CPs for drop-down lists and search-as-you-type. The Master Registry is near-real-time and includes status values, contact details, and controls not available in OTS. The CP Registry format is a strict superset of TOTSCo's OTS / GPLB directory structure so TOTSCo can ingest it with its existing parser; CSF-specific additions are additive and never breaking.

The three tiers are: CP Registry (what MAPs share with each other), Master Registry (the private, converged view used internally by each MAP for routing and PKI), and Directory (the simplified view shared with the MAP's own CPs).

Sponsorship object — as of CSF v2.x the CP Registry also carries a sponsorship object (see §5.4 MAP Section — Field Reference and §5.4.2 Sponsorship Object — Rotation Rules). The TAG (or a prospective candidate MAP) reads the nextSponsor forward pointer to find the current designated Sponsor MAP. The full mechanism is documented in Onboarding & Testing Process §3.4 Sponsor MAP via the CP Registry.

Filter URLs. TOTSCo's pre-production Directory v2 already combines OTS and GPLB entries in one list and distinguishes them by processSupport[].process. MAPs that want a single-process view filter on 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

The CSF's Master Registry follows the same convention.

See Directory & Registry and Directory API for full details.

#Q5 — How does CP-to-CP communication work? Are contact details publicly available?

No, contact details are not public. All CP contact information is held in the registry, accessible only via OAuth 2.0-authenticated API calls. Only those CPs or MAPs that use the CSF network can access the contacts and only after they have been verified and onboarded by a Sponsor MAP and other members of the CSF — they are for operational purposes only.

The registry provides granular contact options:

• OTS-compatible customer-assist and sales-assist URLs (backward compatible).
• Enhanced contacts with phone, email, URL, ticketing-system links.
• Availability hours and days per contact method and purpose (sales, support, technical).
• Preferred contact method at any given time — enabling CPs to route escalations efficiently.

This eliminates the need for offline spreadsheets or specialised swivel-chair tools. A CP's agent can look up the other CP's preferred contact method in real time and raise queries accordingly.

Why the CSF approach replaces the OTS CP-to-CP tool for SforB. The TOTSCo OTS CP-to-CP tool has not been mandated for SforB, and feedback to date has been that it is not fit for purpose for business switching. The CSF's contact-object structure (see §5.6 CP Contact Object) explicitly replaces the need for a separate industry tool — every contact a CP agent might need (sales, support, technical; phone, email, ticketing URL) is available via authenticated API in real time, with availability hours and days, in the same JSON shape across the whole industry.

#Q6 — Will MAPs publish reports? What information will be available to Ofcom?

No regulatory reporting requirements have been identified for SforB at this time (risk RK1, open — see REVIEW.md §3.1). MAPs already collect KPIs for their own commercial relationships. The TAG aims to define a standard set of mandatory baseline statistics with open, consistent calculations; this will be published in a later version of the CSF.

A key improvement over OTS is the ability to track in-session Switch Match failures using an incremented counter in the audit envelope, enabling the industry to distinguish genuine failures from multiple retry attempts for the same sales opportunity.

The TAG itself does not aggregate industry telemetry. This was clarified by the G-6 telemetry-aggregation policy decision (closed 2026-06-16) and is codified in §10.6.7 Anti-Competitive Safeguards. The TAG's role is to define (i) the per-MAP telemetry format and (ii) the collect-and-deliver process to an independent body (Ofcom or OTA2) if one is requested by a regulator. Test traffic is excluded from production telemetry per the JAM audit test=true rule — see Onboarding & Testing Process §5.1 Telemetry Exclusion.

#Q7 — What due diligence is required for onboarding MAPs?

MAPs are expected to complete standard checks during onboarding:

• Credit checks and company registration.
• VAT registration and trading history.
• Fraud checks and ICO Data Protection registration.
• Check any security public-domain records for claims of ISO 27001, Cyber Essentials, or equivalent.

The TAG's Onboarding and Testing Process outlines the specific checks. While the risk of fraudulent CPs masquerading as providers is low, baseline due-diligence guidance still needs to be established as an industry-wide standard (risk RK2).

For MAP-of-1 candidates (a CP taking on the MAP role for itself, including any CP migrating SforB from TOTSCo), the pre-migration capability checklist is at §7.4.4 Pre-Migration Capability Checklist and the Sponsor MAP fast-track for single-cp engagements is at §7.4.5 Sponsor MAP Programme — Fast-Track for single-cp. Sponsor MAPs are not expected to charge for single-cp engagements; where significant support is required, the fee is capped at £350 + VAT (compared with £3,000 + VAT for a traditional multi-CP engagement). One-off, charged once per MAP regardless of protocol footprint.

When onboarding a new MAP, the Sponsor MAP performs the same checks. The effort is typically large, and access to traffic is controlled through the tiered access model.

See Onboarding Phases for the full five-phase plan.

#Q8 — What are the data retention policies?

Data retention is a broader industry discussion and not limited to the CSF (see risk register RK3). Switching data is needed for reporting, investigations, and Ofcom Section 135 requests. No documented requirement for data retention exists under OTS or GPLB, but the CSF has recommended that all of its members retain audit and metadata on transactions for a minimum of 2 years.

For emergency-migration cases the CP Emergency Migration process has explicit audit and retention requirements at §8.2.9 Audit and Retention — five-year retention for the emergency-event log entry, including trigger code, timestamps, RCPIDs of old/new MAP, all rcpidStatusRequest correlation IDs, and outcome (happy/unhappy path). All rcpidStatusRequest traffic itself is retained per §9 audit-log requirements.

#Q9 — If a CP is in test mode, how is this indicated to prevent accidental live switching?

All test traffic MUST be marked as test in the audit envelope. The onboarding MAP overrides this flag until the CP passes exit criteria — even if the CP sets it themselves.

Testing follows a structured process:

1. Local testing: CP tests against the MAP's Virtual Test Host using synthetic data (no messages exchanged with other MAPs).
2. Exit criteria: Hidden unit tests must be passed before production status is granted.
3. Bilateral testing: Only used for bilateral arrangements, with mandatory test flagging.

The full mechanism is documented in Onboarding & Testing Process §4 (Status Model), §5 (Test Traffic Flagging in the JAM envelope), and §5.1 (Telemetry Exclusion). For MAP-of-1 candidates, the Phase 4 operational validation is relaxed — the 72-hour soak and ≥50% bilateral coverage are waived because the CP carries the operational risk directly (see §7.4.9 Phase 4 Relaxation for MAP-of-1). The MAP-overrides-CP test-flag rule remains unchanged for all MAP types.

This is a significant improvement over OTS, which only requires basic connectivity testing and does not address message compliance.

#Q10 — Does the CSF recognise different MAP types? Can a MAP change type?

A MAP is a MAP. The CSF treats all participants equally — no charges, no licensing, no type restrictions.

The CSF is a bit-pipe transport (see Definitions §2.3) — it carries the JAM envelope between MAPs and does not interpret the message body, which is what allows the same transport to carry multiple industry processes (SforB today, OTS Porting and other niche bilateral protocols in future). A CP can become a MAP of 1 by implementing the MAP rules — see §7.4 MAP-of-1 Onboarding (incl. TOTSCo → CSF Migration) for the dedicated onboarding path including the case of a CP migrating SforB from TOTSCo.

Hub MAPs (HMAPs) are a recognised specialisation — TOTSCo participates as an HMAP for SforB per Part 2 §6 TOTSCo Integration and the bilateral TOTSCo HMAP Integration Guide — but the same MAP rules apply at the CSF transport layer.

How any MAP forwards messages to its own CPs internally is outside CSF scope; the framework only governs MAP-to-MAP exchange.

#Q11 — What about high-volume message monitoring and suspension?

MAPs should handle peak loads relevant to their CP base. The CSF provides a minimum rate calculation:

Messages/second = Total Switchable Asset Base ÷ 1,000 (minimum 2/s)

For suspicious or DoS-like patterns, the CSF allows MAPs to:

• Classify a CP as suspicious.
• Broadcast the classification through the directory.
• Implement standard anti-DoS patterns (rate reduction, circuit breakers).

The retry / circuit-breaker patterns are documented under Onboarding & Testing Process §8.7 Retry and Delivery Policy — test IDs R-01..R-18 (behavioural tests R-01..R-09 plus the ratification tests R-10..R-18 that validate the 1 s connection timeout, 3 s response timeout, exponential-backoff shape with jitter, circuit-breaker activation/recovery, bounded retry window, and operational-engagement escalation) and F-01..F-06 in §8.8. The underlying delivery policy itself is now ratified in Part 2 §4.7 Message Delivery Policy.

This is advantageous over a centralised model: CPs are distributed across MAPs, so each MAP handles only its proportional load.

#Q12 — What happens if a MAP exits the market?

The CSF has comprehensive business-continuity built in. The full process is at §8.2 CP Emergency Migration, which sets out:

• Six triggers (§8.2.2): MAP failure (T1), MAP administration (T2), TAG-suspended (T3), TAG-removed (T4), MAP unresponsive (T5), CP-initiated (T6).
• Happy and unhappy paths (§8.2.3 / §8.2.4) — online-original-MAP completes the migration in a few hours; offline-original-MAP caps the outage at ≤ 2 working days, using the CP's own CRM as the authoritative source of in-flight orders.
• Timing targets (§8.2.5) and Normal-vs-Emergency contrast (§8.2.6).
• An Emergency RACI (§8.2.7) for the case where the original MAP is offline or non-cooperative — distinct from the in-flight order RACI in §7.6.
• Fee guidance (§8.2.8) per trigger.
• Audit and retention (§8.2.9) — emergency-event log entry with 5-year retention.

Every MAP MUST support emergency on-boarding of an existing CP as a core capability.

See Commercial Scenarios for the detailed procedures.

#Q13 — How does the CSF support a CP currently using TOTSCo for SforB who wants to move to a CSF MAP-of-1?

This is the strategically important "TOTSCo → CSF" escape path. The full route is documented at §7.4 MAP-of-1 Onboarding (incl. TOTSCo → CSF Migration). Headlines:

• SforB only. OTS is Ofcom-mandated to TOTSCo and stays at TOTSCo unchanged.
• Same five-phase on-ramp as a traditional new MAP onboarding (§7.2), with the Phase 4 relaxations noted in Q9 above for single-cp engagements.
• Sponsor fees are free by default; capped at £350 + VAT for single-cp engagements when significant support is needed (versus £3,000 + VAT for traditional multi-CP). The Sponsor MAP fast-track at §7.4.5 trims scope further where appropriate.
• Big-bang cutover — the industry directory carries a brand once per process, so the cutover is atomic.
• In-flight orders are either drained on TOTSCo or reconciled from the CP's CRM (CP's choice — see §7.6).
• New UUIDv4 RCPID allocated for SforB; legacy TOTSCo SforB Rxxx retired (§7.4.8).
• TOTSCo wind-down for the SforB element follows TOTSCo's commercial-exit terms; OTS contracts are unaffected.

The CSF treats this as a first-class industry-adoption journey.

#Q14 — Where does the CSF sit in relation to OTS, and can a CP migrate OTS to CSF?

OTS stays at TOTSCo. OTS is mandated by Ofcom to use TOTSCo as the single industry platform — there is no OTS migration to the CSF.

The CSF is the business-switching transport (SforB) and, over time, the transport for niche bilateral protocols and any future industry protocols the TAG adds to its baseline (for example, OTS Porting where Ofcom permits a non-mandated technical solution). A CP that operates both OTS and SforB on TOTSCo today can move only the SforB element to a CSF MAP-of-1; OTS continues on TOTSCo unchanged.

See §7.4.1 Definition and Scope for the formal scope statement.

#Q15 — How are disputes between MAPs resolved?

Three tiers per §10.6.4 Dispute Resolution:

• Tier 1 — direct between the MAPs, using CP-Registry contact details. Target resolution within 5 working days.
• Tier 2 — TAG mediation at the next weekly steering-group meeting.
• Tier 3 — binding adjudication by an external independent body appointed by the TAG. OTA2 is the TAG's preferred candidate for the standing Tier-3 adjudicator role, subject to OTA2's formal acceptance.

Interim measures during any dispute require both MAPs to continue exchanging messages normally — disputes cannot be used as a reason to block or degrade service to CPs.

#Q16 — What enforcement does the TAG have over a misbehaving MAP?

Graduated enforcement per §10.7 Enforcement:

1. Written warning — 10 working days to remediate.
2. Probation — status flagged in the registry; voting suspended.
3. Suspension — CPs encouraged to migrate; the MAP cannot accept new CPs.
4. Removal — 30-day TAG remediation window before the MAP is removed from the Master Registry.

CP continuity is the explicit priority over enforcement — affected CPs invoke §8.2 CP Emergency Migration under trigger T4 ("TAG-removed"). A draft additional clause on anti-competitive behaviour (proposal P-3) is awaiting legal review and may add specific anti-competitive-conduct triggers in a later CSF version.

#Q17 — Sponsor MAP rotation — how does it actually work?

Every onboarded MAP joins a decentralised FIFO rotation via a sponsorship object in its CP Registry (see §5.4.2 Sponsorship Object — Rotation Rules and the full mechanism in Onboarding & Testing Process §3.4 Sponsor MAP via the CP Registry).

Key rules:

• The token advances on acceptance of an engagement, not on completion — so long onboardings never block the queue.
• Concurrent sponsorships are supported via a per-MAP capacity field (minimum 1, no upper bound).
• A single-cp engagement (MAP-of-1) counts as 1 against capacity, the same as a traditional multi-CP engagement.
• Optional fields allow a Sponsor MAP to advertise a self-service registration URL (sponsorship.registrationURI) and attach an internal ticket reference per engagement (active[].candidateRef).

#Q18 — Can a CP self-register with a Sponsor MAP?

Two discovery paths.

Primary — the TAG-published sponsor-registration page (URL to be published by the TAG) which lists the current designated Sponsor MAP and a registration contact, updated whenever the rotation advances.

Fallback — read any existing MAP's CP Registry, find the entry with the most recent nextSponsorUpdated, and contact that MAP's map/contact[] entries (or its optional sponsorship.registrationURI if it provides one).

See §7.4.6 Finding your Sponsor MAP.

#Q19 — What does it cost?

Transport: zero. No CSF licensing fees, no per-message charges, no annual subscriptions, no MAP-participation fees.

The recurring saving from removing TOTSCo SforB subscription and per-unit charges is documented at §7.4.11 Cost Model — Qualitative.

#Q20 — Does the CSF interact with the SforB Response Codes that GPLB-SG controls?

No. SforB Response Codes (the 9xxx industry series and any SforB-specific codes) are controlled by GPLB-SG and published via FCS. The CSF transport carries the codes verbatim in the message body and does not interpret them.

The CSF's own error codes are the 8xxx series — PKI verification errors only. The CSF's bit-pipe principle (see Definitions §2.3) means the transport never inspects the message body; the SforB Response Codes therefore continue to be controlled by the SG without any CSF involvement.

#Q21 — How does the CSF align with the OTA2 GPLB Message Delivery Principles?

The CSF's delivery policy is now ratified in Part 2 §4.7 Message Delivery Policy. The CSF and the OTA2 Switching for Business Message Delivery Principles V0.2 describe different architectures — the GPLB principles are hub-side (TOTSCo intermediates between RCPs); the CSF is peer-to-peer synchronous (MAPs exchange directly). Both share 1 second connection timeout and 3 second response timeout as the narrow convergence point.

The asymmetry is deliberate. CSF's P2P model has a synchronous response on every delivery attempt, so the hub-side queueing, retry-until-12-days, single-flight, and async failure-notification mechanisms are not applicable. Persistent failure escalates through inter-MAP operational engagement, not silent retry. The full architectural rationale is in the analysis report at wiki/syntheses/csf-compliance-with-gplb-message-delivery-principles.

#Document Control