---
title: 8. Commercial Scenarios
tags: [Part 2]

---

# 8. Commercial Scenarios

> Connected Services Framework (CSF) — Part 2: Implementation — Version 2.0

## 8.1 Overview

The CSF addresses several commercial scenarios that were not fully covered by OTS. These scenarios are critical for ensuring business continuity, CP autonomy, and consumer/business protection.

## 8.2 CP Emergency Migration

**CP Emergency Migration** is the reactive process by which a CP transfers to a new MAP under one of the §8.2.2 trigger conditions (most often a failing, suspended, removed, or unresponsive MAP). It contrasts with a *normal* CP transition (§7), which is planned and CP-driven on a commercial timeline. The CSF mandates that every MAP supports emergency on-boarding of an existing CP as a core capability.

### 8.2.1 Definition and Scope

Emergency migration applies when the CP needs to move with little or no notice — usually because the current MAP can no longer be relied on to sign, route, or audit the CP's messages. It is *not* a substitute for a normal transition (§7); it is the framework's safety net.

Under OTS, a CP cannot move its in-flight orders between MAPs without significant manual effort, and the same risk exists if a MAP enters administration. The CSF addresses this by:

- Decoupling the CP from the MAP through DNS-controlled identity (§6)
- Enabling CPs to move freely between MAPs (or across multiple MAPs under different brands)
- Mandating that every MAP supports in-flight order export as a core capability (§4)
- Providing the `rcpidStatusRequest` flow so a new MAP can reconstruct or import in-flight state from the old MAP (§4) or, when the old MAP is offline, from other MAPs holding the orders

### 8.2.2 Triggers

Any one of the following invokes CP Emergency Migration:

| # | Trigger | Source / authority |
|---|---|---|
| **T1** | MAP failure / outage (technical, not by TAG decision) | Operational |
| **T2** | MAP enters administration or insolvency | Statutory / commercial |
| **T3** | MAP **suspended** by TAG (after governance review) | §10 governance — `SUSPENDED` directory status |
| **T4** | MAP **removed** by TAG (after 30-day remediation window) | §10 governance — removal from Master Registry |
| **T5** | MAP unresponsive (operationally unreachable but not formally suspended) | CP / TAG-observable behaviour — repeated `rcpidStatusRequest` non-response, `9301` reject noise above threshold, sustained failure to advertise in directory |
| **T6** | CP-initiated emergency (CP invokes emergency rather than normal transition — e.g. MAP material breach of MoU / SLA) | CP–MAP commercial contract |

Triggers T1, T2, T5 cover the "MAP can't do its job" cases. T3 and T4 are TAG-driven and are also referenced in the **draft Anti-Competitive Enforcement clause** — to be published as an **Appendix to the CSF framework** once it has been legally reviewed and signed off by the TAG members (tracked as P-3 in the open-conflicts log). Until the Appendix is published, T3/T4 follow the existing §10.7 graduated enforcement ladder. T6 covers the rare case where the CP itself elects to invoke the emergency process.

### 8.2.3 Happy Path — Distressed MAP Still Online

When a MAP is in distress but still operational:

1. The CP establishes a new MAP relationship and updates DNS
2. The new MAP advertises the CP and sends `rcpidStatusRequest` to the original MAP
3. The original MAP responds with in-flight order exports
4. Other MAPs detect the directory change and update routing

If the CP appears in both directories temporarily, **conflict management** resolves it automatically using DNS verification (the CP's `_mapkey` is the tiebreaker — see §6.5).

The new MAP SHOULD advertise the distressed MAP as being in "conflict," signalling other MAPs to verify their CP associations with that MAP.

Migration can be completed in **a few hours** if the new MAP expedites CP onboarding.

### 8.2.4 Unhappy Path — Distressed MAP Offline

If the failing MAP cannot perform exports:

1. The CP contacts a new MAP and completes onboarding
2. The CP uses its own CRM records to identify in-flight orders
3. The new MAP issues `rcpidStatusRequest` to **other MAPs** involved in those in-flight orders
4. All new requests use new correlation IDs
5. Switch Matches without Switch Orders can be re-issued (they are not part of the export)

During the offline period:
- The CP will not appear in any directory or drop-down lists
- Messages cannot be exchanged for the affected CPs
- Any order updates must be managed with prospects and supply chains manually

> All MAPs can onboard new CPs within hours, so the offline period is not expected to exceed **2 working days**.

### 8.2.5 Per-Scenario Timing Targets

Three different commitments apply, depending on which path is in play:

| Scenario | Target window | Path |
|---|---|---|
| **Planned MAP change** (not an emergency) — normal CP transition with TTL pre-staging | **Single-digit minutes** of actual outage | §7 + the DNS TTL pre-staging routine (§3.3) |
| **Happy-path emergency** — distressed MAP still online; `rcpidStatusRequest` exports succeed | **A few hours** | §8.2.3 |
| **Unhappy-path emergency** — distressed MAP offline; CRM-based reconstruction | **≤ 2 working days** | §8.2.4 |

These are framework targets; an individual MAP's MoU may commit to tighter numbers commercially.

### 8.2.6 Normal Transition vs Emergency Migration — Contrast

| Attribute | Normal CP Transition (§7) | CP Emergency Migration (§8.2) |
|---|---|---|
| **Trigger** | CP-driven commercial decision | One of the §8.2.2 triggers (T1 – T6) |
| **Notice** | Planned, weeks to months | None — reactive |
| **TTL pre-staging** | Yes — 24 h+ before cut-over | Not possible (no advance notice) |
| **New-MAP onboarding pace** | Standard | Expedited — CP treated as an experienced user |
| **Original MAP's cooperation** | Required for in-flight export | Best effort; CRM fallback if offline (§8.2.4) |
| **In-flight order recovery** | Exported by old MAP via `rcpidStatusRequest` | Imported via `rcpidStatusRequest` (happy path) **or** reconstructed from CP CRM + sibling MAPs (unhappy path) |
| **Fees / costs** | Per CP – new-MAP commercial agreement | See §8.2.8 — depends on trigger |
| **Target window** | Single-digit minutes (online) | A few hours (happy) / ≤ 2 working days (unhappy) |
| **TAG involvement** | None | None unless triggered by §10 (T3 or T4) |
| **Audit log requirement** | Normal (§9) | Normal **plus** explicit emergency-event log entry (§8.2.9) |

### 8.2.7 Emergency RACI

This RACI applies to the emergency process specifically. The in-flight-order RACI for *normal* transitions is in §7.6.

| Activity | CP | New MAP | Old MAP | Other MAPs | TAG |
|---|---|---|---|---|---|
| Identify trigger and decide to migrate | A/R | I | I | I | I (T3/T4 only) |
| Select new MAP | A/R | I | I | — | — |
| Expedited onboarding | C | A/R | I | — | — |
| Generate new PKI keys; update CP DNS (`_domainkey`, `_mapkey`) | A/R | C | — | — | — |
| Advertise CP in new registry | I | A/R | — | I (via directory sync) | I |
| Issue `rcpidStatusRequest` to old MAP (happy path) | I | A/R | C (if online) | — | — |
| Reconstruct in-flight orders from CP CRM (unhappy path) | A/R | C | — | — | — |
| Issue `rcpidStatusRequest` to sibling MAPs holding the orders | I | A/R | — | C (must respond) | — |
| Re-issue Switch Matches lacking Switch Orders | I | C | — | A/R | — |
| Mark old MAP as **"in conflict"** in directory | — | A/R | — | I | I |
| Emergency-event audit log (§8.2.9) | C | A/R | C (if available) | C | I |

R = Responsible · A = Accountable · C = Consulted · I = Informed

### 8.2.8 Fee Guidance

Fees for an emergency migration depend on which trigger applies:

| Trigger | Fee treatment |
|---|---|
| **T1 / T2** — MAP failure or administration | New-MAP expedited-onboarding at the new MAP's **standard published rates**; the CP is not at fault. A new MAP MAY waive expedite fees as goodwill / market practice. |
| **T3 / T4** — TAG-suspended or TAG-removed MAP | Same as T1/T2 by default. The **draft Anti-Competitive Enforcement clause** — to be published as an **Appendix to the CSF framework** once legally reviewed and signed off by TAG members (tracked as P-3 in the open-conflicts log) — would require waiver of expedite fees on the receiving side; until the Appendix is published, the T1/T2 treatment applies. |
| **T5** — MAP unresponsive | Same as T1/T2. The CP MAY seek recovery from the unresponsive MAP under their MoU. |
| **T6** — CP-initiated emergency | New-MAP **standard onboarding fees apply** as for a normal transition; the CP is electing the emergency path. |

In all cases, the new MAP MUST publish its expedite-onboarding charge alongside its standard onboarding charge (transparency requirement, §10).

### 8.2.9 Audit and Retention

Both happy- and unhappy-path emergencies generate an **emergency-event log entry** that the new MAP MUST persist. The entry SHALL contain at minimum:

- Trigger (T1 – T6 from §8.2.2) and free-text reason
- Timestamps: decision-to-migrate, DNS update, new-registry advertise, first `rcpidStatusRequest` issued, all completed
- Old MAP RCPID and new MAP RCPID
- List of `rcpidStatusRequest` correlation IDs issued and which responded
- Outcome: "happy" (all responses received) or "unhappy" (CRM reconstruction used)
- Any in-flight orders re-issued with new correlation IDs

Retention:

- **Happy path** — exported in-flight order package retained alongside the new MAP's normal CSF audit logs per the data retention policy in §9 (5 years).
- **Unhappy path** — the CP's CRM-reconstruction record forms the authoritative in-flight set for the affected interval and SHOULD be retained for the same period; the new MAP records the reconstruction inputs received from the CP.
- **All `rcpidStatusRequest` and response messages** issued or received during the emergency MUST be persistently logged per §9 audit-log requirements.

### 8.2.10 CP Emergency Migration Checklist

- [ ] CP contacts new MAP and agrees terms
- [ ] New MAP treats the CP as an experienced user (expedited onboarding)
- [ ] New PKI keys generated and DNS records updated (`_domainkey`, `_mapkey`)
- [ ] New MAP advertises CP in its registry
- [ ] `rcpidStatusRequest` issued to original MAP (if available) and affected sibling MAPs
- [ ] In-flight order data imported (happy) or reconstructed from CP CRM (unhappy) and reconciled
- [ ] Emergency-event audit log entry written (§8.2.9)
- [ ] Old MAP marked "in conflict" in the new MAP's directory (where applicable)
- [ ] Full operations resume

## 8.3 CP Merger, Acquisition, and Consolidation

CPs involved in mergers may need to consolidate brands over time. The CSF supports this through a staged process:

### Stage 1 — Stop Selling

Mark consolidating brands as not accepting new Switch Matches (but still process in-flight orders and handle losses).

### Stage 2 — Asset Migration

Move customer assets from stop-sell brands to the surviving RCPID. During this period:
- The stop-sell brands remain in the directory
- The current MAP continues to handle any losses for those brands
- Care must be taken if this extends over a long period

### Stage 3 — Close In-Flight Orders

Complete all remaining in-flight orders on consolidating brands. For any remaining orders:
- Complete gains
- Cancel losses where appropriate
- Migrate remaining customer assets to the surviving RCPID

### Stage 4 — Remove Brands

Remove stop-sell brands from the MAP's directory. This signals to other MAPs that those CPs no longer exist. The RCPIDs are:
- Retained in time-series data for audit records
- Archived under normal data retention policies
- Never reused for different brands

## 8.4 CP Going into Administration

When a CP enters administration with outstanding in-flight orders:

### MAP Responsibilities

1. **Hold all in-flight orders**: Switching to a CP in administration would have greater impact on end consumers than maintaining the status quo
2. **Continue processing outbound switches**: All in-flight orders transferring **away** from the CP in administration MUST continue to be processed, even if the MAP is not being paid
3. **Suspend new business**: The MAP sets the CP status to `SUSPENDED` in the directory
   - No new Switch Matches or Switch Orders will be processed
   - Existing customers are locked with their current provider under business continuity terms
4. **Await resolution**: Continue until the CP is recovered by another party or managed by an appointed insolvency team

### Industry Considerations

The response of a MAP when a CP enters administration MUST be formally defined by each individual MAP and is outside of the scope of the CSF. Refer to [OTA2 guidance](https://www.offta.org.uk/siteassets/ota/solr-industry-process.pdf?v=384772) 

## 8.5 Summary of Built-in Protections

| Scenario | OTS Capability | CSF Capability |
|---|---|---|
| CP changes MAP | Significant manual effort | Seamless — DNS update + RCPID Status export |
| In-flight order portability | Not supported | Built-in via standardised JSON export |
| MAP failure (online) | Limited options | Automated conflict resolution + export |
| MAP failure (offline) | Major disruption | CP emergency migration within 2 working days |
| Brand consolidation | Ad-hoc | Staged process with directory controls |
| CP administration | Undefined | Defined responsibilities with status controls |